The world of open source software, and Linux/GNU in particular, is a strange one, governed by internal politics and beliefs. Now frustration seems to have the better of the Linux developers who are now considering creating their own Linux call library.

If you write programs for Linux you will have encountered the phenomenon of the missing function call that implements some aspect of the operating system. Usually your only choice is to try and remember how to make a syscall and looking things up in the documentation. Usually, you can create your own simple wrapper in a few minutes and then you are left wondering why this isn't in the standard Linux C library glibc?

The glibc library supports both the C and C++ standards and POSIX 1 and 2 standards and some of the omissions are likely due to the syscall being Linux-specific, but there are a lot of Linux-specific function wrappers included in glibc, usually indicated by a name ending _np for non-portable, so why not all syscalls?

The answer isn't easy to find. It seems that the glibc programmers are sometimes pushed for time and sometimes they simply don't like a syscall. This is strange because you might think that the role of a library developer would be to wrap all syscalls and make them easy to use in user space while trying to keep as much portability as possible. Instead glibc programmers critique the Linux syscalls and refuse to support any they don't like for a wide range of reasons. It really is too late to critique a syscall after it has been designed and incorporated into the operating system, but this is what seems to be happening.

In practice the wait for glibc support can be a long one - for example, if you want to use the deadline scheduling, which was introduced into the mainline kernel in 2014, it still doesn't have a wrapper and might never get one. Not only does this make deadline scheduling seem more difficult to the potential user, it also makes it seem less supported and hence better to avoid.

The frustration has finally come to the surface in the Linux Kernel mailing list:

Daniel Colascione

Official Linux system wrapper library?

Now that glibc is basically not adding any new system call wrappers, how about publishing an "official" system call glue library as part of the kernel distribution, along with the uapi headers? I don't think it's reasonable to expect people to keep using syscall(__NR_XXX) for all new functionality, especially as the system grows increasingly sophisticated capabilities (like the new mount API, and hopefully the new process API) outside the strictures of the POSIX process.

Later posts point out that saying that glibc isn't accepting any more Linux-specific wrappers is an overstatement, but generally the feeling is that a new Linux call library is a good idea.

Could it be that glibc is trying to serve too many standards?

Could it be that POSIX is just a distraction given that Linux has so many extensions and is a de facto standard in its own right?

Part of the problem seems to be the governance of glibc:

Michael Kerrisk:

People may have disappeared from glibc development who have objected to gettid. I thought this was the case with strlcpy/strlcat, but it was not.

At present, it takes one semi-active glibc contributor to block addition of a system call. The process to override a sustained objection has never been used successfully, and it is a lot of work to get it even started.

Gettid is perhaps the most notorious case of glibc not wrapping a syscall because of disapproval of its very existence. It may be a bad call but its in the OS and it should be made easy to use by the provision of a simple function wrapper.

There follows suggestions that the Linux people should cooperate more with the glibc people, but you can tell that there is a lot of history to be overcome.

Part of the culture clash is due to different concerns:

Florian Weimer

Several glibc contributors deeply care about standards compliance for header files. The kernel developers care not, and the result is that we copy definitions and declarations from the kernel header files, creating additional problems.

It is doubtful whether anything will happen but the concern and frustration are real.

You have to come to the conclusion that the "benevolent dictator" model has a lot of advantages.

More Information

Official Linux system wrapper library?

Related Articles

Visual C++ For Linux

Linux Adopts New Code of Conduct; Linus Apologizes and Takes a Break

Linus On Linux And Strong Language 

GCC Gets An Award From ACM And A Blast From Linus      

Guido van Rossum Quits As Python BDFL 

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info