[Clfs-dev] Embedded: Is e2fsprogs really needed in core embedded book?

Joe Ciccone jciccone at gmail.com
Fri Apr 8 18:54:38 PDT 2011


On Tue, 2011-03-29 at 06:18 -0400, Andrew Bradford wrote: 
> 
> 
> For embedded, the "beyond" section is in the book.  It's where
> dropbear, iptables, libnl, and hostapd live.  The CBLFS packages at
> cblfs.cross-lfs.org are, in my opinion, more intended for the regular
> book.
> 
> 
> The embedded book is small partly because it's a bit of a work in
> progress, but also because BusyBox provides quite a lot of the core
> functionality required and because most embedded systems need to fit
> in small quantities of flash memory.  The embedded landscape spans a
> huge variety of storage media sizes, for example, the WRT54GL router
> only has 4MB of flash, some newer routers have _HUGE_ capacities of
> 32MB, and my BeagleBoard-xM has a 4GB SD card.  The book should be
> able to be made to work for all of those sizes (32MB is easily done
> with the present book, 4MB would require getting rid of e2fsprogs and
> paring down BusyBox).

I propose creating a filesystems section under the beyond chapter and
move e2fsprogs there. Tools for all the different filesystems can be
added there, as many or as few as need be. ext*, jffs2, squash, reiser2,
jfs, xfs, or whatever else you might find on an embedded board. 
> 
> This could be a good idea, provided there's an easy way to determine
> which packages will actually work on the embedded build.  Regular CLFS
> has quite a different set of packages and thus some basic dependencies
> may not be met as easily with the embedded build.  If you've
> successfully built any of the CBLFS packages for your embedded system,
> please let me know.  I'm not sure if there's a good way to indicate a
> package works with embedded on the CBLFS wiki.  If there is, update
> that too, please.

I'm not even sure if the embedded book should point at either BLFS or
CBLFS. It's one of those things were you really can't follow either one.
Especially for the embedded book because of uClibc. As compatible as it
is with Glibc there are a lot of threading problems that always seem to
come up. 
-- 
Joe Ciccone




More information about the Clfs-dev mailing list