[klibc] klibc and udev

[Kay Sievers]

On Mon, 2006-08-14 at 10:11 -0700, H. Peter Anvin wrote:
> 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 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()

Udev doesn't use getopt_long at the moment, but module-init-tools would
need it, right?

> - fnmatch()

Yeah, that would be nice, so I can just use fnmatch() instead of our own
matching function.

> Buffered stdio I'm a bit ambivalent about, although I have been close to 
> adding it several times.  How bad is fgets(), really?

It was much too bad to use it, the time we had this in the early udev.
Reading the udev rules file was ~100.000 characters to read with fgets()
for every /sbin/hotplug event forked udev binary. I just switched to
mmap() that time to solve that. Glibc is the same speed with the custom
mmap() and fgets().
The current udev does not read any config/rules file for an event, so
this is not an issue anymore.

Udev would need getgrnam() getpwnam() too. It may be enough, to have
simple functions which return 0 for "root" and NULL for everything else,
if you don't want to implement /etc/passwd,group lookup. In initramfs it
should be fine, if everything belongs to root.
I'm planning to remove the udev built-in passwd lookup (used only when
built with klibc), and expect getgrnam(), getpwnam() to be available for
linking.

Thanks,
Kay