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

[sjs205]

On 04/09/2011 03:48 PM, Joe Ciccone wrote:
> On Sat, 2011-04-09 at 13:22 +0100, Hector Oron wrote:
>> 2011/4/9 Andrew Bradford<bradfa at gmail.com>:
>>
>>> I think if people are successful getting stuff to build and run
>>> properly on an embedded build, it'd be nice to know.  I'm not sure of
>>> the best format, (C)BLFS wiki versus book versus some other medium.
>> I'd like to test it for ARM, but I always have trouble to find out
>> which it latest and greatest (to test).
> I'll be honest, I would rather see a book style system instead of a
> wiki. Even for the beyond parts. Maybe wrap a web interface around it
> where someone can commit a change. The reason I would rather see this is
> a problem we've had in the past with releases of clfs. We can't really
> take a snapshot of cblfs to store with clfs. So if you're building the
> woefully outdated clfs 1.1.0 the currently cblfs may have some issues
> building on top of it as it is expecting some changes in clfs-dev.
>
> For now I say just keep the beyond stuff for embedded in the book itself
> just in its own section/chapter system. That way in the future it would
> be easy to move out into its own book if we ever want to separate it.
>
> In the coming weeks I'm going to continue the work I started on the
> stylesheets to simplify the XML. That should make maintaining something
> like that MUCH easier.
>
>>> Which then has to beg the question, would moving embedded to EGLIBC be
>>> something to consider?  My impression is the 'E' stands for embedded,
>>> but I'm not sure if it's as small as uClibc (I'm assuming it's not).
> I'd say no, embedded should stay uClibc. Reasoning below.
>> EGLIBC is GNU Libc (Glibc) with some patches on top so it allows
>> better integration with embedded systems. For example, it fixes
>> install headers target when building cross compilers, it has support
>> for multicore ARM chips, supports building with -Os, etc... it can be
>> built to be fully compatible with Glibc, but it can also be built
>> disabling some of its fat (iconv stuff, etc..) making it _not
>> compatible_ with Glibc. EGLIBC is just an easier to work with C
>> library when comparing to Glibc. uClibc vs EGLIBC, it probably needs
>> testing and benchmarking, but rumor has it that uClibc performace and
>> small(ish) size cannot be beaten but a shrink down EGLIBC, but for me
>> it is just a rumour.
> You hit this pretty much spot on. However the sysroot book was created
> before embedded, it's purpose is to have the full gnu userspace where
> the embedded book is super minimal. As small as possible. A user could
> easily adapt a build using a mixture of the 2 books that builds eglibc
> but instead of the gnu tools uses the instructions for busybox in the
> embedded book.
>

Yo all,

Those who have been following the IRC will have noticed that I am in the 
process of getting the OPIE user interface 
http://en.wikipedia.org/wiki/OPIE_user_interface built on my ARM board 
with the clfs-embedded base. Since this is part of my dissertation I am 
having to log all steps in the process.

With this in mind, I would like to add all that I have to the beyond 
part... and there is quite a bit...

Agree that it is a good idea to keep it as part of the book, although a 
wiki is so much easier - IMHO - to edit, however, a web wrapper would be 
perfect!

I am happy to help with whatever is required, although I am currently 
bogged down with this dissertation - and will be until late may.  But I 
would love to take an active role in the books development... give a 
little back so to speak.

sjs205