[OE-core] [RFC PATCH 1/1] self-hosted-image: generate the .hdddirect and .vmdk image files

[Cui, Dexuan]

Darren Hart wrote on 2012-01-17:
> On 01/17/2012 01:35 AM, Cui, Dexuan wrote:
>> Darren Hart wrote on 2012-01-13:
>> So, I think here we should change the = to ?= like the below -APPEND
>> = "root=/dev/sda2"
>> +APPEND ?= "root=/dev/sda2"
>> And in meta/conf/machine/include/qemu.inc, I can add a line APPEND =
>> "root=/dev/hda2".
>> 
>> Does this sound ok?
> 
> That seems appropriate to me.
I decide not to change the line in boot-directdisk.bbclass and I think adding
a line
APPEND_${MACHINE} = "root=/dev/hda2"
in qemu.inc should be ok.
This is because ?= can have some side effort, i.e., in the case of atom, in
atom-pc.conf, APPEND is already assigned a value that isn't suitable for syslinux. 

>> 
>>> 
>>>>  TIMEOUT = "10"
>>>>  SYSLINUXCFG  = "${HDDDIR}/syslinux.cfg"
>>>>  SYSLINUXMENU = "${HDDDIR}/menu"
>>>> @@ -50,6 +51,7 @@ build_boot_dd() {
>>>> 
>>>>  	install -d ${HDDDIR}
>>>>  	install -m 0644 ${STAGING_DIR_HOST}/kernel/bzImage
>>> ${HDDDIR}/vmlinuz
>>>> +	install -m 0644 ${S}/syslinux.cfg ${HDDDIR}/syslinux.cfg
>>> 
>>> Hrm... syslinux.cfg wasn't installed before at all?
>> I'm not very clear about the history, but according to
>> syslinux.bbclass, iso and hddimg do invoke syslinux_populate, but
>> hdddirect doesn't -- I suppose hdddirect doesn't need all the
>> functionality of build_syslinux_menu, so it tries to install the
>> files itself, and unluckily it misses syslinux.cfg. Now there is no
>> user of .hdddirect in poky, and I don't know there is any actual
>> external user. This may explain why nobody complains. :-)
> 
> This sounds like an opportunity to modularize and reuse to me.
Agree. We should try to improve the code here in future.

>> 
>>> 
>>>>  	install -m 444 ${STAGING_LIBDIR}/syslinux/ldlinux.sys
>>>> ${HDDDIR}/ldlinux.sys
>>>> 
>>>>  	BLOCKS=`du -bks ${HDDDIR} | cut -f 1` @@ -83,6 +85,12 @@
>>>>  build_boot_dd() { 	cd ${DEPLOY_DIR_IMAGE} 	rm -f
>>>>  ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect 	ln -s
>>>>  ${IMAGE_NAME}.hdddirect
>>>> ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect
>>>> +
>>>> +	if [ "${NOVMDK}" != "1" ] ; then
>>>> +		${STAGING_BINDIR_NATIVE}/qemu-img convert -O vmdk   \
>>> 
>>> You've added a dependency on qemu-img, please add the appropriate
>>> DEPENDS above.
>> I have added the line in my patch:
>> do_bootdirectdisk[depends] += "qemu-native:do_populate_sysroot"
>> 
>> I think this is enough?
>> Need I add "DEPENDS += "qemu-native", too?
> 
> No, I don't think so. Is do_populate_sysroot the right task? That
> would be my guess as well, but we should be confident.
I think it should be ok: do_populate_sysroot installs the utility qemu-img
into the sysroot and this is all we need.

>> 
>>> 
>>>> +			${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect \
>>>> +			${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.vmdk +	fi
>>>>  }
>>>>  
>>>>  python do_bootdirectdisk() {
>> 
>>> Darren Hart wrote on 2012-01-13:
>>> On 01/10/2012 10:53 AM, Dexuan Cui wrote:
>>> 
>>> A couple additional thoughts about the boot-directdisk class in general:
>>> 
>>> So build_boot_dd needs a careful audit to ensure the various dd
>>> commands do not stomp on eachother iirc, the dd of syslinux/mbr.bin
>>> was stomping on the partition table or some such.
>> Hi Darren, The dd-ing of mbr.bin actually writes only the first 440
>> bytes of $IMAGE -- please note the size of mbr.bin(generated by the
>> recipe syslinux, I think) is 440 bytes rather than 512 bytes. :-) I
>> think 440 is safe enough because it's even smaller than 512-16*4=448
>> bytes.
>> 
>>> Also note that it uses "mkdosfs -d" which we have purged (and it
>>> aint coming back if my NACK is worth anything ;-). Sounds like we
>>> need to abstract building msdos images into an msdosfs.bbclass. No
>>> reason to
>> Would you volunteer to make a msdosfs.bbclass? :-)
> 
> Not in the near future unfortunately, I'm heavily overloaded as it is.
> That said, please open a bug and we can find an appropriate owner.
Ok, I opened a bug http://bugzilla.pokylinux.org/show_bug.cgi?id=1913.  

>>> duplicate all the fatfs overhead calculations I did yesterday (See
>>> the patch I sent yesterday to bootimg.bbclass).
>> I agree.
>> I see your patch has been in poky master now.
>> If you could help to make msdosfs.bbclass, I would appreciate that a lot.
>> Now I'm stick in something else and I'm afraid I can't start to work
>> on this immediately. :-(
>> 
> 
> Understood. Open the bug and explain what's needed and we'll
> prioritize and assign it. There may also be others who would like this
> feature that would be willing to pick up the task.
Hi Darren,
Thanks for all the comments!
I'll send out the v2 patch and Cc you.

Thanks,
-- Dexuan