[klibc] klibc and udev

[Aaron Griffin]

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