[meta-intel] meta-intel.inc: Update INTRD to INITRD_LIVE

[Patrick Ohly]

On Wed, 2016-03-30 at 17:12 +0800, Robert Yang wrote:
> 
> On 03/30/2016 04:45 PM, Patrick Ohly wrote:
> > Hello Saul!
> >
> > I noticed that you changed meta-intel.inc from extending INITRD to
> > INITRD_LIVE:
> >
> > meta-intel rev: cdbf029110327a51c0
> >
> >      This address a boot issue based on using the new bootimg code that
> >      makes a distiction between Live and VM type of image so they can
> >      co-exisit.
> >
> >   # for the early boot time kernel microcode loading support,
> >   # merge the microcode data in the final initrd image.
> > -INITRD_prepend = "${@bb.utils.contains('MACHINE_FEATURES', 'intel-ucode', '${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"
> > +INITRD_LIVE_prepend = "${@bb.utils.contains('MACHINE_FEATURES', 'intel-ucode', '${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"
> >
> >
> > In Ostro OS, we are not using bootimg. Our own code still uses INITRD,
> > which means that we no longer including the microcode.cpio in our
> > initramfs.
> 
> I think that if you don't use booimg (live), but use vm (virtual machine) image,
> AFAIK, INITRD is a must for live image (hddimg, iso), but optional for vm image,
> if you are sure that only vm is needed, then you can change the line to:
> 
> INITRD_VM_prepend = "${@bb.utils.contains('MACHINE_FEATURES', 'intel-ucode', 
> '${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"

Now it gets even more confusing, with a third INITRD variant thrown into
the mix.

Is it explained somewhere what these variables mean and when one is
supposed to use which variable?

INITRD_LIVE = "live boot CD"
INITRD_VM = "virtual machine"
INITRD = "real hardware" 

Something like that?

Either way, was the commit added to ensure that the live boot CD
continues to use microcode, or was it added to ensure that VM images do
not use it? Saul?


-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.