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

[Peter Bigot]

On Mon, Nov 14, 2011 at 9:07 AM, Koen Kooi <koen at dominion.thruhere.net> wrote:
>
> 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.

Yes, but they're default-assigned, so an override in local.conf would
apply to both, no?  Why does x-load allow them to be overridden?
Maybe that'd be a clue as to the right way to change the point-of-use.

What's the point of adding a nomachine symlink anyway?  A desire to
avoid specifying the target filename in the cp command?  Consistently
using MLO-${MACHINE} for the source and MLO for the target would be a
lot more clear, since the target absolutely must be named "MLO".

meta-ti now has two things that can create an MLO file (x-load and
u-boot) and a third thing that uses it (sdcard_image), and they're
inconsistent in how they name it.  Ick.

>> * 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.

As far as I can tell, that (both inherit and set) is exactly how it's
done normally.

Personally I'd like to see a lot of cleanup in sdcard_class before it
got merged to oe-core image_types.  Among other things, the ability to
create the images for the partitions independently, and only
optionally combine multiple partitions into a whole-disk image.  Most
of the time I'll have a pre-formatted sd card and only want to update
the rootfs partition.

Besides, a generic name like "sdimg" almost certainly shouldn't be a
class that only knows how to build boot partitions for OMAP boards
that require MLO.

Peter

>
> regards,
>
> Koen
> -----BEGIN PGP SIGNATURE-----
>
> iEYEARECAAYFAk7BLsYACgkQMkyGM64RGpHYhQCfbQcmAJJCZvCyLeoHU4JlTl6e
> YOEAn298tyHdEDA+IAk/Zi979pn1nv/g
> =CvBb
> -----END PGP SIGNATURE-----
>
>