[meta-intel] [PATCH 1/1] README: Documentation of hardware features

[Kamble, Nitin A]

On 10/3/14, 9:57 AM, "Paul Eggleton" <paul.eggleton at linux.intel.com> wrote:

>Hi Nitin,
>
>On Friday 03 October 2014 16:33:28 Kamble, Nitin A wrote:
>> On 10/3/14, 4:15 AM, "Paul Eggleton" <paul.eggleton at linux.intel.com>
>>wrote:
>> >On Thursday 02 October 2014 14:14:41 nitin.a.kamble at intel.com wrote:
>> >> From: Nitin A Kamble <nitin.a.kamble at intel.com>
>> >> 
>> >> Starting a new documentation section to describe the layer specific
>> >>
>> >>hardware
>> >>
>> >> features. At this point the intel-ucode machine feature is described
>> >>
>> >>here.
>> >>
>> >> In the future more such features will be described in this section.
>> >
>> >This looks fine to me, thanks for revising it.
>> >
>> >Speaking of the feature itself, I do wonder if going forward whether
>>only
>> >a MACHINE_FEATURES item is the best way to control this though -
>> >particularly if the decision to include it or not is about image size
>>or
>> >policy, users may want to be able to control it at the distro or image
>> >level, and MACHINE_FEATURES is not meant to be changed outside of the
>> >machine configuration. Perhaps we can revisit this in 1.8? (I regret
>>that I
>> >didn't take the opportunity to get involved with this earlier, my
>> >apologies.)
>> 
>> Paul,
>>    Thanks for the response. To me it feels best to leave it to machine
>> configuration space. Handling from image or distro configuration space
>> does not seem right. If the machine need/can use updated microcode then
>> that reason is valid for all kinds of distro or image configurations. It
>> is very processor specific decision, and it is best handled in the
>>machine
>> configuration.
>
>You yourself stated:
>
>"The BSPs which are highly sensitive to the target image size, which are
>not 
>experiencing any microcode related issues, may consider not enabling this
>feature to save the target image foot print."
>
>However, it's not really the "BSP" that is sensitive to the target image
>size, 
>for a lot of cases it's going to be dependent on how the device is to be
>used 
>(what storage is going to be used for the image, how large I want my
>image to 
>be, etc.) We may supply a BSP for a device where microcode updates are
>available and can be applied, but that doesn't mean that all usages of
>that 
>device need or want to include the microcode update functionality. Hence
>to my 
>mind it ought to be able to be controlled independently of the BSP.

I think this can be explained better with an example. For example take a
wearable BSP, it would not be building a big image. So the BSP is tied to
a restricted size of the image. Sato or SDK kind of images may not make
any sense for the BSP. In this case the feature can go in the machine
configuration. Ideally it would be nice to have this as a default disabled
feature in the poky-tiny distro, but that is not ideal for the
non-wearable kind of BSPs. I am not trying to reach any conclusion here,
but making sure we have all the information and understanding to make the
right decision. I hope all this clarifications would help you in making
the distro/image feature decision for microcode.

Cheers,
Nitin


>
>Cheers,
>Paul
>
>-- 
>
>Paul Eggleton
>Intel Open Source Technology Centre