klibc - Aug 2006 - klibc and udev

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

Assuming some minor breakage in the near future, is klibc open to
accepting patches for "basic C features", such as fnmatch and/or
getopt_long?


---------- Forwarded message ----------
From: Kay Sievers <kay.sievers at vrfy.org>
Date: Aug 14, 2006 9:46 AM
Subject: Re: [ANNOUNCE] udev 097 release
To: Aaron Griffin <aaronmgriffin at gmail.com>
Cc: Tobias Powalowski <t.powa at gmx.de>, linux-hotplug-devel at
lists.sourceforge.net

On Mon, 2006-08-14 at 09:27 -0500, Aaron Griffin wrote:
> On 8/14/06, Kay Sievers <kay.sievers at vrfy.org> wrote:
> > Klibc is not officially supported, but udev should still build with it
> > (I don't test it though). The more complex initramfs setups need
tools
> > that will probably never compile with klibc cause they use threads.
> >
> > Also simple stuff like long commandline options or fnmatch() isn't
> > supported by klibc. Or it is very very slow cause of the unbuffered
IO,
> > for fgets() like functions, which syscall into the kernel for every
> > single character they read.
>
> Would you be interested in bug testing, assuming the stdc functions
> are not patched in?
I have no real interest, I just recommend not using it to build udev.
> i.e. If I were to send a patch which doesn't change anything on the
> gcc side, but fixes something with klibc, would it be responded to
> with "klibc isn't supported" or not?
Depends on how intrusive they are, simple stuff should be fine. But
ifdef __KLIBC__, or code that implements standard stuff that klibc
doesn't support is no longer accepted.

I'm tired of not using basic stuff like long options, fnmatch(),
fgets(), ... cause of klibc's limitations, and I don't make any promises
not to start using these standard interfaces some day.

Kay

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....
> 
> Assuming some minor breakage in the near future, is klibc open to
> accepting patches for "basic C features", such as fnmatch and/or
> getopt_long?
> 
Yes, but some care needs to be spent in avoiding bloating these 
features.  Just copying them out of another libc isn't likely to cut it.

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

As far as fgets() is concerned, adding buffered input is something I'm 
willing to consider if there is demand for it.  It's unfortunately a 
fair bit of code which affects all users of stdio, which is why I 
haven't actively added it.

fnmatch() I'm conflicted about, because it's really typically a thin 
wrapper around the regex engine.  If anyone can come up with a small 
implementation of it, though, I'm willing to take it.

	-hpa

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 :)

thanks,

greg k-h