Kernel Developers Debate Having An Official Linux System Wrapper Library

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[hoohoo]

"systemd" the project, not the init.

Hmmm, can you elaborate?

[starshipeleven]

Hmmm, can you elaborate?

systemd project contains stuff that isn't strictly systemd init and is also more or less optional. Like logind, or systemd-boot.

a C library can't really become systemd-only by its own definition (it's basically as low as it can get in the stack, it sits between the kernel and userspace applications, even the init system can only be an user and not a dependency of it) unless you really believe systemd developers are cartoon evil characters bent on conquering the world.

[Weasel]

It would kind of be the same reason why ntdll.dll was not made pure inline.

ntdll is not a header so you can't make it inline and what you said makes no damn sense.

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.

Classic. Spoken like a true noob, but I'm not surprised in the least.

Fun fact: the inline keyword, which is the topic here, has nothing to do with actual inlining decisions. The only thing they share is the name ("inline"). If you want that you have to use attributes, like __attribute__((always_inline)) (GCC) or __force_inline (MSVC). inline keyword is a storage specifier.

For C++ (your ntdll, you know, Windows is written in C++): https://stackoverflow.com/a/1759575
C++ even has "inline variables" which use the same semantics, and no, you cannot apply __force_inline on them since it makes no sense.

It differs in C but it depends on the C standard so it's more complicated (C89 is different than C99).

It's a great noob trap because it's so effective, and I'm not at ALL surprised it caught you, lol. Continue embarrassing yourself though.

EDIT: just in case the link goes down:

inline is more like static or extern than a directive telling the compiler to inline your functions. extern, static, inline are linkage directives, used almost exclusively by the linker, not the compiler.