[klibc] klibc and udev

H. Peter Anvin hpa at zytor.com
Mon Aug 14 10:11:53 PDT 2006

Greg KH wrote:
> On Mon, Aug 14, 2006 at 09:58:36AM -0500, Aaron Griffin wrote:
>> In case people here don't follow the udev mailing list, udev seems to
>> be quasi-dropping klibc support.  Well, see the forwarded message
>> below.
>> As I don't agree with the "omg udev is complex! use glibc!" rationale,
>> I want klibc and udev to remain working with each other....
> The big issue with udev not using klibc is that you don't want a long
> running daemon to use klibc because of the memory management usage of
> klibc.
> Look at the free() implementation for what I mean :)

Actually, that really shouldn't affect a long-running daemon that much. 
  What it *does* affect is the case where you have a daemon which uses 
up lots of memory at one time, and then drops it down.

Also, as you can tell :), there isn't really a big deal to add the code 
to release memory back to the system, especially when using the mmap() 
form of memory allocation.  If this is an issue I'll certainly explore 
that.  Do remember, too, though, that this is userspace, and memory 
allocated but not used can be swapped out once the swap device comes 
online.  Doesn't help the embedded folks, though.

As I said in my previous email:

> What is definitely right out: regular expressions, locale support, 
> thread support.  This isn't about reinventing uclibc.

Functionality I'm definitely willing to add if there is demand, and the 
implementation is lean enough:

- Memory reclaim
- getopt_long()
- fnmatch()

Buffered stdio I'm a bit ambivalent about, although I have been close to 
adding it several times.  How bad is fgets(), really?  If it really is 
that bad, I'd be willing to consider adding at least buffered input. 
The sucky bit is that it probably means stdio gets dependent on malloc.


More information about the klibc mailing list