Kernel Developers Debate Having An Official Linux System Wrapper Library

[hoohoo]

"systemd" the project, not the init.

Hmmm, can you elaborate?

[starshipeleven]

That would make it essentially impossible to use Linux going forward without systemd. As such I cannot agree with you.

"systemd" the project, not the init.

[starshipeleven]

But as always, bugs are taking ages to be fixed in Linux, even though it's open source.
Hopefully initiatives of this type will help with this kind of cases.

The main issue for that is that there is too little people paying for it so the resources are limited.
This type of initiatives might help but aren't the real solution.

[hoohoo]

You know, all trolling aside, I think it probably should. Libc should be just that, a library providing APIs and standard functions for the C language, and therr should be a separate system library for everything that interacts with the kernel. Windows NT and successors have always done this, and it has proven a good approach.

That would make it essentially impossible to use Linux going forward without systemd. As such I cannot agree with you.

[brrrrttttt]

I know you're just trolling here, but syscalls have ALWAYS been part of a stable API. Anything between kernel and userspace has always been stable, only the internal guts is allowed to change.

It's like there are people who have never read any of the good Linus rants.

[Uqbar]

I dislike this very direction.

First because it adds more code to the kernel tree that won't add any feature but will force a number of devs to major reworks with few benefits if any.

Second, performance will see a drop. A tiny one, but still a drop.

Third, more code equals to more bugs.

Fourth, it will solve maybe a tiny fraction of the problems it aims to.

[jacob]

The window being has highly split from C standard is more of a major historic stuff up. Lot of Linux syscalls are posix standard C.

http://man7.org/linux/man-pages/man2/syscalls.2.html

Like syscall open is a 1 to 1 match to the fcntl.h open in posix standard.

These 1 to 1 matches kind of blur the line. Of course nothing says glibc developers could not properly implement filter and auxiliary in versioned and pull kernel .so functions when it suits.

There are *some* matches like that, and many more that don't match at all. All socket-related stuff is vastly different at the kernel level. POSIX thread primitives are implemented using entirely different system calls (clone, futex etc). (Near-)POSIX ACLs are implemented using setxattr()/getxattr() etc.

Then libc also contains things like printf() , fopen(), strncpy() etc. that only make sense for programs compiled in C, plus a DNS resolver (another historical idiosyncrasy that should have been long fixed), a dynamic linker, math functions etc. Basically libc has become a kind of catchall to run any GCC output on Linux. It should be split into several components:

- a kernel interface library supporting the system calls interface (not necessarily POSIX), /sys and /proc accessors and, presumably, ld.so and its support. This should be part of the kernel release cycle and would be the one component everything relies upon for ensuring compatibility between versions;

- an actual libc library that only contains POSIX primitives (which only really matter in C) and the standard C runtime. This would only be used by C programs, obviously, no need for Rust or Go binaries to link against it as they do now against the whole libc;

- a set of service libraries to be used by all languages that would provide DNS resolution, localisation, date/time management, dbus interface etc. This should ideally be part of the systemd project.

[oiaohm]

Why would you not inline a call to an instruction that's smaller than the call itself? Seriously?

It would kind of be the same reason why ntdll.dll was not made pure inline. Better handling of deprecated/removed syscalls. Also if you wish to be able to override the function in userspace.

That's literally the whole point of the inline keyword. And the linker will discard all but 1 (if they aren't inlined forcefully, which they should be).

Sorry this is not linker work. Someone has not read compiler documentation.

https://msdn.microsoft.com/en-us/library/bw1hbe6y.aspx

The insertion (called inline expansion or inlining) occurs only if the compiler's cost/benefit analysis show it to be profitable. Inline expansion alleviates the function-call overhead at the potential cost of larger code size.
This is the Microsoft one but I could just as simply quote the gcc or llvm ones the optimisation may discard all but 1 or if it makes a perform call that is faster inlined every point that is inline may be still there.

Also its not the linker that makes the inlining judgement call its the compiler. Yes Link Time Optimization in a linker the resend the object files back past the compiler optimisation engine. Now if you program is made from 1 object file the inline will be as solved as they are going to be when the object was made. So discards of inlines are done first in the object production stage then a second round of discards of inlines can happen again in the linking stage. But these discards do not say their will be only 1 copy left of inlines.

If you want only 1 copy you have to use a normal function this partly avoids the compiler code/benefit analysis doing something you are not expecting.

You know, all trolling aside, I think it probably should. Libc should be just that, a library providing APIs and standard functions for the C language, and therr should be a separate system library for everything that interacts with the kernel. Windows NT and successors have always done this, and it has proven a good approach.

The window being has highly split from C standard is more of a major historic stuff up. Lot of Linux syscalls are posix standard C.

http://man7.org/linux/man-pages/man2/syscalls.2.html

Like syscall open is a 1 to 1 match to the fcntl.h open in posix standard.

These 1 to 1 matches kind of blur the line. Of course nothing says glibc developers could not properly implement filter and auxiliary in versioned and pull kernel .so functions when it suits.

[smitty3268]

It almost feels like after 30 years they finally start to realize the importance of a standard API. Almost.

I know you're just trolling here, but syscalls have ALWAYS been part of a stable API. Anything between kernel and userspace has always been stable, only the internal guts is allowed to change.

[ngraham]

No wonder I'm still waiting to see the folder / file creation date / time in KDE's file manager:

https://phabricator.kde.org/D7423

Even though the statx system call was added in Kernel 4.11:

https://kernelnewbies.org/Linux_4.11#Prominent_features

Which was released more than a year and a half ago.

I wondered if anyone would bring this up.

Indeed, the proposal would be a huge help. As you've noticed, my patch stalled because of the lack of a glibc interface, and I'm not really a good enough programmer to figure out how to do the raw syscalls. Now that there is finally a glibc interface, it's still sufficiently different from the old stat call (no backwards compatibility) that it requires a lot of code refactoring. To be honest, I got kind of demoralized and forgot about it when I got busy with other things.

If anyone here is a C++ and kernel wizard and wants to pick this up, I'd be more than willing to hand it over!