[Clfs-dev] CLFS Embedded

Andrew Bradford andrew at bradfordembedded.com
Mon Oct 21 05:59:47 PDT 2013


On 10/19/13 22:50, Neil Bradley wrote:
> Iptables is very useful, as is libnl & hostapd if you want your device to be a hotspot. This is functionality I will need in the near future, but I was okay with not installing these at the current stage. There might be a good chance the enthusiast would appreciate this kind of configurability. Is there a suitable alternative, or perhaps this belongs in CBLFS instead?

I think iptables, libnl and hostapd should go into a cblfs type wiki or
other document.  Many people who will read the embedded book won't want
or need them but if you're building a router, you would want them.
However, I'd like to keep a few more likely used packages, like
e2fsprogs or dropbear, in the book as many people will want or have a
use for them beyond just what busybox offers.

Sadly, there's no cblfs targeted at embedded right now, so that's
something we'll have to fix first.  On a brighter note, since now the
toolchain and targetfs are separate, making a cblfs for embedded should
be less hard.

If you don't agree with this, I'll gladly accept patches to add back
hostapd and libnl (and fix up iptables) (libnl should go into
beyond-libs section).  I personally don't have a use for them so don't
really know how to tell if they're working or not.  But if you do, and
you're willing to send patches to the book for working configurations,
I'll apply them.

> Regarding e2fsprogs & dropbear...
> I haven't tested with the latest dropbear, I'll rebuild later this week, but the situation was thus:

> I'm targeting ARM1176; the version of dropbear previously used had configuration scripts (config.guess and config.sub) dating from 2007, which don't support the architecture. I updated those scripts  to the latest versions from Savannah. I haven't tested with the new dropbear.

OK, let me know what you find.  I'll be doing some armv7-a builds this
week, too.

> I'm not quite sure where the issue with e2fsprogs came in; I surmised that it was due to the target arch not having an unsigned 64-bit type. It's only used in 1 small section of ext2fs/unix_io.c that is for very large filesystems - but rather than just commenting it out, I rewrote it using an unsigned 32-bit type that the ARM supported.
> 
> lib/ext2fs/unix_io.c: 933 - 940:
> 
> #ifdef BLKDISCARD
>         __uint64_t range[2];
> 
>         range[0] = (__uint64_t)(block) * channel->block_size;
>         range[1] = (__uint64_t)(count) * channel->block_size;
> 
>         ret = ioctl(data->dev, BLKDISCARD, &range);
> #else

OK.  I'll try to take a look at this, too.

Thanks,
Andrew


>> Date: Thu, 17 Oct 2013 15:05:31 -0400
>> From: andrew at bradfordembedded.com
>> To: neil.bradley at windowslive.com
>> Subject: Re: CLFS Embedded
>>
> 
>  ...
>  
>>
>>> 11.5.1 - iptables had same issue with config.? - but was in build-aux directory.
>>> --enable-libipq misspelt?
>>> Conflicts between net/if.h & linux/if.h : 
>>> change net/if.h to linux/if.h in ipt_headers.... .h & include/xtable.h
>>> also netinet/in.h to linux/in.h
>>> also had u_int instead of uint
>>> These issues in both 1.4.19.1 & 1.4.20.0
>>
>> Yeah, programs that include both libc and linux headers are annoying
>> with musl as it separates itself from Linux quite well (it's one of the
>> only libc that doesn't rely on linux headers in order to build).
>> Busybox does something similar, thus the somewhat ugly sed lines there
>> to remove building of ifplugd.
>>
>> I'd like to fix ifplugd, as it's a nice feature.
>>
>> Is it worth keeping iptables for a normal embedded build?  I think this
>> might again be more WRT leaking into the book for people wanting to
>> build a router, which isn't really the direction I want to take the book.
>>
>>> e2fsprogs: 
>>> ioctl had an issue with 2x 64-bit block sizes in BLKDISCARD
>>> changed to using 4x 32-bit in ext2fs/io_ctl.c
>>
>> OK.  I'll open a trac ticket for this.
>>
>> Can you write up the e2fsprogs and dropbear issues in a slightly cleaner
>> way?  I'm not fully sure I fully grok them (and I've not yet build
>> tested them recently).




More information about the Clfs-dev mailing list