LinuxConf.eu: Documentation and user-space API design [LWN.net]

LinuxConf.eu: Documentation and user-space API design

Posted Sep 4, 2007 9:17 UTC (Tue) by michaeljt (subscriber, #39183)
Parent article: LinuxConf.eu: Documentation and user-space API design

If people did not access kernel interfaces directly, but only through shared libraries, that would greatly limit the number of places where changes needed to be made if a kernel ABI was broken, and make it much more feasible to remove unwanted ABIs. The shared libraries need not be maintained by the kernel people, they would just need to accept the responsibility of tracking ABI changes. MS stopped guaranteeing the stability of their kernel ABIs years ago - might the same not work in the Linux world?

Not to mention the added portability benefits of using shared libraries over direct use of ABIs - as shown by Wine :)

(Log in to post comments)

Libraries

Posted Sep 4, 2007 9:52 UTC (Tue) by michaeljt (subscriber, #39183) [Link]

That is currently a conscious decision though. It would equally well be possible to require people upgrading their kernel to upgrade system-critical libraries in sync. Current interfaces carry a stability guarantee, but in theory (read, in my idle speculation :) new ones could be labled as "not guaranteed, only access through a library". And anyone writing such a library would be aware of their responsibility.

In the end, a system which should not be changed can keep with a given kernel.

Libraries

Posted Sep 4, 2007 12:20 UTC (Tue) by nix (subscriber, #2304) [Link]

That way lies alsa-lib, commonly regarded (by seemingly everyone but the ALSA developers) as a really Bad Idea.

Libraries

Posted Sep 4, 2007 13:49 UTC (Tue) by michaeljt (subscriber, #39183) [Link]

Anything can be done wrong :) (Note that I have never programmed Alsa, so I can't comment there.) However, glibc essentially does the same, with the difference that at least on Linux the underlying interfaces are guaranteed. And unlike Alsa the interfaces and the library are maintained by different people, which might not be such a bad thing.

Libraries

Posted Sep 4, 2007 14:56 UTC (Tue) by nix (subscriber, #2304) [Link]

glibc provides an interface between kernel syscalls and userspace, yes, but interfaces don't appear in glibc until the kernel syscall ssemantics have been nailed in stone, and glibc then maintains those semantics forevermore, using compatibility code to ensure that if necessary (see e.g. the behaviour of nice()).

Requiring a shared library to access the kernel

Posted Sep 4, 2007 14:05 UTC (Tue) by jreiser (subscriber, #11027) [Link]

I have written more than handful of useful software that must access the kernel directly through an absolute system call interface. The interfaces of glibc cannot provide the required services, which include self-virtualization, auto relocation, introspection, control over binding, small size, speed, etc.

The history of glibc with regard to interface stability is not pretty, either. For example: @GLIBC_PRIVATE, hp_timing, _ctype_, *stat(), errno. It's important that both the kernel interfaces and the libc interfaces be well designed and well implemented and well documented.

Requiring a shared library to access the kernel

Posted Sep 5, 2007 0:29 UTC (Wed) by bartoldeman (guest, #4205) [Link]

'info libc' for Glibc 2.6.1 tells me:
This is Edition 0.10, last updated 2001-07-06, of `The GNU C Library
Reference Manual', for Version 2.3.x of the GNU C Library.
which does not look very promosing.

It would be great if someone could fund a technical writer to work on this manual... the POSIX threads documentation still talks about Linuxthreads instead of NPTL, and many of the new functions mentioned in NEWS are not documented at all, or documented elsewhere.

For instance, ppoll(2) is in the man pages but not in the glibc manual, and there are many others.

I usually try to check both man pages and info to be sure.