| |||||||||||||
Glibc and the kernel user-space APIGlibc and the kernel user-space APIPosted Jan 30, 2013 18:31 UTC (Wed) by samroberts (subscriber, #46749)In reply to: Glibc and the kernel user-space API by michaeljt Parent article: Glibc and the kernel user-space API
Wasn't there an article in the last year about the kernel perhaps including a userspace library as a part of it's source? That seems a decent place to put "raw" syscall wrappers.
I think C callable functions with prototypes would offer better type-checking than macros that generate syscall(), and one reason to NOT use syscall directly is to get the arg types correct.
(Log in to post comments)
Glibc and the kernel user-space API Posted Jan 30, 2013 19:14 UTC (Wed) by kpfleming (subscriber, #23250) [Link]
A header file with the appropriate 'static inline' functions would serve this purpose nicely; it doesn't need to be compiled and distributed as a library, but the function calls are type-checked and can be written more easily than preprocessor macros.
Glibc and the kernel user-space API Posted Jan 30, 2013 21:48 UTC (Wed) by justincormack (subscriber, #70439) [Link]
You would have to namespace them though, as they mainly have the same names as existing libc functions...
Glibc and the kernel user-space API Posted Jan 30, 2013 23:41 UTC (Wed) by and (subscriber, #2883) [Link]
> You would have to namespace them though, as they mainly have the same names as existing libc functions...
The same is true if you would use macros
Glibc and the kernel user-space API Posted Jan 31, 2013 1:19 UTC (Thu) by skissane (subscriber, #38675) [Link] 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:
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").
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.
|
|||||||||||||