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

[Koen Kooi]

Op 14 nov. 2011, om 16:32 heeft Peter Bigot het volgende geschreven:

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

u-boot and x-load are now internally consistent with naming nowadays.


-------------- 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/987d278d/attachment.pgp>