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

[Paul Eggleton]

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.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre