| |||||||||||||
LibrariesLibrariesPosted Sep 4, 2007 9:52 UTC (Tue) by michaeljt (subscriber, #39183)In reply to: Libraries by corbet Parent article: LinuxConf.eu: Documentation and user-space API design
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.
(Log in to post comments)
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()).
|
|||||||||||||