On Wed, 24 Feb 2010 07:48:29 -0800 Mark Mitchell <mark@xxxxxxxxxxxxxxxx> wrote: > Alexander Gordeev wrote: > > >> I don't think glibc/eglibc is the right place for this file. > >> GLIBC is principally an implementation of the library requirements > >> of the C and POSIX / Single Unix standards; this is not part of > >> those standards. > > > > Didn't know that glibc implements only POSIX, thanks for the > > clarification! > > It certainly implements a good bit more than POSIX. And, of course, > the POSIX C library specification is a somewhat random amalgamation of > stuff; it's not like there's a logical justification for including > exactly the set of math functions present, but no more. > > I don't know anything about PPS, but if these are new Linux system > calls or equivalents then I think (E)GLIBC is a very good place for > them. The *NIX C library has historically been the library that > provided the userspace interface to kernel functionality. We could > have had libio for read/write/open/close and libtime for > times/gettimeofday and libsocket for accept/send/recv, but instead > all that just went into libc. > > So, I don't really understand why this shouldn't go in. This header file indeed wraps custom Linux char device ioctl's. I was always thinking about glibc in the very same way: library that provides the user-space interface to kernel functionality. -- Alexander
Attachment:
signature.asc
Description: PGP signature