Glibc and the kernel user-space API [LWN.net]

Glibc and the kernel user-space API

Posted Jan 31, 2013 1:19 UTC (Thu) by skissane (subscriber, #38675)
In reply to: Glibc and the kernel user-space API by samroberts
Parent article: Glibc and the kernel user-space API

Officially GNU LibC is not just to support the Linux kernel, but other kernels as well. Of course, in reality Linux is the main kernel it gets used with, but the portability is a nice idea to maintain.

This suggests it is useful to distinguish new functionality into two groups:

functions that another kernel could well implement, even if no other kernel does so right now; functionality that could potentially be standardised as part of SUS/POSIX, even if it isn't right now
functionality which is inherently very kernel-specific, and while other kernels may provide the functionality, they are likely to do so with rather different API designs. These kinds of functions are unlikely to ever be standardised, and there is little value in providing cross-kernel APIs for them

I think module loading, kexec, etc., really belong to group (2). That then suggests, that these functions don't belong in LibC, but instead in some separate Linux-specific library or header file (a "liblinux").

(Log in to post comments)

Glibc and the kernel user-space API

Posted Jan 31, 2013 3:36 UTC (Thu) by raven667 (subscriber, #5198) [Link]

While I'm no software engineer it seems to be that there are inherent complexities and inefficiencies in trying to abstract away non-standard features and in preventing them from being used in the main body of code, to be relegated to a separate support library. You can't pervasively make full use of possibly useful features because you have to support more impoverished environments which might not have the feature, or might have the feature but with a highly incompatible API. If you try to use the local APIs of each OS then you may end up with a different implementation for each OS, wrapped in ifdefs.

I think there is a real debate that should happen to figure out where the best place is to draw the lines for cross platform compatibility. Should one use the OpenBSD model where there is a core project that takes full advantage of all the OpenBSD-only features along with a separate project for porting that to other systems. What about the rest of user space, of desktops, where should things be tied to the particular OS by using OS features and where should things be designed for the lowest common denominator, or where is it acceptable to provide multiple implementations with ifdef.

Glibc and the kernel user-space API

Posted Jan 31, 2013 14:26 UTC (Thu) by bkw1a (subscriber, #4101) [Link]

I'm currently experimenting with the Ceph distributed filesystem, which can make use of "syncfs" if it's available. I'm running a kernel that supports syncfs (The ElRepo kernel-ml-3.7.5-1), but on a distribution (CentOS 6.3) that doesn't have a glibc that knows about this function. It would be nifty if the kernel came with a "liblinux" that implemented things like this, instead of the daunting (non-starter, really) prospect of upgrading to a new glibc just to get syncfs.