[meta-ti] [PATCH 1/2] sdcard_image bbclass: fix MLO copy, loop device mounts, fstypes

[Koen Kooi]

Op 14 nov. 2011, om 15:57 heeft Peter Bigot het volgende geschreven:

> On Sun, Nov 13, 2011 at 12:42 PM, Koen Kooi <koen at dominion.thruhere.net> wrote:
>> 
>> Op 13 nov. 2011, om 19:25 heeft Peter A. Bigot het volgende geschreven:
>> 
>>> From: "Peter A. Bigot" <bigotp at acm.org>
>>> 
>>> Generalize the search for MLO to install to have correct path for copies
>>> placed in ${DEPLOY_DIR_IMAGE} by x-load.inc, and to continue for SPL builds
>>> where there is no MLO.
>>> 
>>> Allow user to override the loop mount point as well as the loop device, for
>>> folks who don't want long paths to temporary directories in their fstabs.
>>> 
>>> Add noauto to example fstab entries so systems will boot without attempting
>>> to mount an unconfigured loopback device.
>>> 
>>> Remove IMAGE_FSTYPE_append which does not belong in this class.
>> 
>> I like the fstab changes, but not the others, could you please split this patch?
> 
> So I can prepare more appropriate patches now and in the future, please explain:
> 
> * Why do you want to hard-code the MLO symlink paths in the install
> and deploy directories instead of using the bitbake variables that
> x-load.inc uses for those paths?

Due to variable scoping those are only available inside those recipes, not the image class.

> * Why do you want IMAGE_FSTYPE to be extended with .tar.bz2 when this
> class has nothing to do with tar.bz2 images?

It used the tar.bz2 rootfs to populate the extX partition in the past, but it looks like it can go away now.

> * Why do you want IMAGE_FSTYPE to be set in the class when every other
> image recipe in openembedded puts IMAGE_FSTYPE modifications in the
> recipe that incorporates the image?

That was a hack to make inheriting the class "just work". I'm not sure how to proceed on this one, do we merge this into image_types.bbclass in OE-core or not? If there's enough support for requiring to both inherit the class and to set IMAGE_FSTYPES to sdcard we can move it.

regards,

Koen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.yoctoproject.org/pipermail/meta-ti/attachments/20111114/f5ef2375/attachment.pgp>