[Ltib] Re: nb31xx platform patch for review

[Stuart Hughes]

Hi Miguel,

Miguel Angel Ajo Pelayo wrote:
> Hi Stuart, I agree with you
> 
> El 19/11/2010 0:42, Stuart Hughes escribió:
>> Hi Miguel,
>>
>> Thank you for the patch and my apologies for the delay getting back to
>> you.
> 
> Don't worry, It's perfectly ok :-)
> 
>> 1/ The deploysd.sh script
>>
>> I can see what you're doing here, but I'm reluctant to include this
>> because:
>>
>> * Running sudo cp is a too much of a security compromise
>>
>> * Also if we were to support this it would be better to do this by
>> having rootfs.tmp created directly on the SD card and then not deleting
>> this staging area.  However the issue is that unless you run this as
>> root, the owners would be incorrect and there would not be any device
>> nodes (even udev needs a few static nodes.
>>
>> In the mean time, if it works for you, then that's fine, but I'd be
>> cautious about distributing this to others (due to the sudo cp security
>> thing).
> 
> What do you think about leaving the "sudo" responsibility to the final
> user instead
> of including it in the deploysd.sh?
>
> sudo bin/deploysd.sh   rootfs....    /media/sdcard

That's better I think, but for now I think it's best to keep this script
in config/platform/_your_target_ for now as I'm not sure that this is
exactly the approach I'd use.

> 
> Finally I rewrote the deploysd (not sure if it's in that patch) to:
> a) mount -o loop the ext2  image on /tmp/xxxxxx
> b) then copy the files to the SD
> c) umount both the loop and the SD
> d) sync
> 
> I did it this way, because rootfs.tmp don't keep the right GID/UID for
> the final filesystem.
> may be we could find a better way to do it..
>

Actually the UID/GID are all root/root in the ext2/jffs images as they
get created from the rootfs.tmp and it's just the processors that handle
them (genext2fs and mkfs.jffs2) that do the change of user/group.

A better way may be to just dd the ext2 image to the SD card and then
use re-size fs, a few less steps.  The worry is to make sure no mistake
is made with the output device.


>> 2/ All the binary config/platform/nb31xx/merge/lib/firmware/* files need
>> to be removed.  The reasons are architectural and legal.
>>
>>  From the architectural point of view, LTIB tries very hard to have no
>> content as part of the tool (just references).  This keeps the
>> distribution out of LTIB. The exception is limited use of merge
>> directories to override things like /etc/hostname, /etc/fstab etc, which
>> at least are plain text and so just about okay.  Putting binary content
>> would be plain incorrect as it then means LTIB includes package content
>> that exists external to LTIB.
>>
>>  From a legal point of view, you need to be careful.  I see one of the
>> binaries has a zd1211/License saying it's GPL/MPL so maybe that one is
>> okay, but if it is, then a GPL source package is better.  For the others
>> you need to be absolutely sure you have a legal license to freely
>> distribute these binaries.  So I would recommend this:
>>
>> * Remove from your patch
>>
>> * Create package for these (binary if needs be)
>>
>> * Make certain that anything you intend to distribute from your PPP is
>> legally freely distributable by you
>>
>> * If you can be sure that one or more of these binaries are freely
>> distributable under some recognisable license they could be put onto the
>> GPP (if you prefer).  However anything with a restrictive license cannot
>> go onto the GPP.
>>
>>
> Yes I thought about that too, I think I will keep our PPP for this
> binary package and then,
> if that licensing issues get resolved and clarified then we could
> include them in
> the GPP.

Okay.

> 
>> 3/ If you can use the standard busybox.config then please do and just
>> remove it from the patch
> 
> I'd must really check, I think there are some setup that I want to
> include by default
> that's not included in the standard busybox.config (like mdev support)
> 

I thought mdev was in the standard config.  If not then we could/should
put it into the general one.  If there's anything else missing from the
general one, then it may make sense to just update that.  The size delta
is not that critical and the one we have now is not set in stone.


>> 4/ I can't merge in your %ppp_url, you'd need to add that adaptation in
>> at the time you make your BSP release.  However I do think there are
>> hooks in the release script (IIRC) that help you do this.
>>
> Of course, that's right now in the patch to let my current users use
> ltib after applying our
> patch. But I understand perfectly that it should be removed for
> integration in ltib.
> 

Take a look at bin/Ltibrelease.pm to see how you can get ./ltib -m
release to apply this kind of change and make an iso image for you.  It
may do what you need, rather than requiring uses to do anything.


> Thanks mr. Stuart
> 

You're welcome.

Regards, Stuart

>> Regards, Stuart
>>
>>
>> Miguel Angel Ajo Pelayo wrote:
>>> The first patch is here:
>>>       http://pkgs.nbee.es/nb31xx/ltib/ltib_nb31xx_v1.patch
>>>
>>> And I have a couple of doubts:
>>>
>>>     1) I have included a new script command in bin/ for the ltib
>>> platform, it's called "deploysd.sh" Is it ok?
>>> it's meant to mount a rootfs.ext2.gz image using a loop device, and
>>> making a copy to an SD card, for
>>> systems that have root filesystem on SD card.
>>>
>>>     2) Under the nb31xx directory I've setup some binary files that will
>>> be copied to the lib/firmware directory
>>> of the platform, all of them are for running wireless devices over USB.
>>>
>>>          Should we setup a separate package? or keep those files out of
>>> ltib main site?, is ist already in some package?
>>>
>>>     I think that's all :)
>>>
>>> Thanks again!
>>>
> 
>