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