[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Ltib] Re: nb31xx platform patch for review

From: Miguel Angel Ajo Pelayo
Subject: [Ltib] Re: nb31xx platform patch for review
Date: Fri, 19 Nov 2010 12:37:54 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; es-ES; rv: Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6

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

What do you think about leaving the "sudo" responsibility to the final
user instead
of including it in the

sudo bin/   rootfs....    /media/sdcard

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

 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.

 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)

 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.

Thanks mr. Stuart

 Regards, Stuart

 Miguel Angel Ajo Pelayo wrote:
 The first patch is here:

 And I have a couple of doubts:

     1) I have included a new script command in bin/ for the ltib
 platform, it's called "" 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!

Miguel Angel Ajo Pelayo
+34 636 52 25 69
skype: ajoajoajo

reply via email to

[Prev in Thread] Current Thread [Next in Thread]