Hacker News Reader

Comment by bregma | Hacker News Reader

You could serialize everything through epoll(): use signalfd() to redirect signals into epoll(), use eventfd() for IPC through epoll(), etc. The kernel programming API is that everything is operated on through a file descriptor, not that everything is a file. You misunderstand.

You can program in another language other than C and avoid using GNU libc, or Musl libc, or any other libc, so avoid using the C API to talk to the kernel. Other languages like Rust and Go provide their own runtimes and avoid using the C runtime for syscalls. Syscalls are written in assembly language, or at least syscall(2) itself is because the kernel API is just marshalling and a context switch. You misunderstand.

Oh, and the fork(2) function on Linux is implemented by a libc using the clone syscall(2). The (2) is the chapter in the manual providing the documentation. You misunderstand.

View on HN

Go has tried to avoid libc where possible, but Linux is rather unusual in that raw syscalls can be done reliability with assembly code. Rust just uses libc to sidestep the hassle (and perhaps better interface with C code, not sure).

While I think that most of your reply is pretending to not notice the real problem and making lame excuses, I specifically want to point out this:

> You can program in another language other than C and avoid using GNU libc

Linux is a set of various system interfaces. Many of which are exposed through libc functions. If you deliberately exclude libc and program something parallel to it instead, then you aren't really using Linux. You've created a hybrid system. This only reinforces OP's complaint about not being able to program in a different language, because, in other words, this means that to C language programmer Linux is available fully, and to other languages the functionality is not completely available.

Take, for example, async I/O, which is implemented in libc around other system primitives, s.a. threads. If you don't use libc, you don't have async I/O, and by extension, you don't have Linux, since Linux is supposed to have that.

This is a surprising take.

Linux as a project is the kernel. Unlike most OSes, the most commonly used libc is maintained separately. As a result, Linux the operating system is the one where it’s the most common and supported to avoid the “standard” libc because the kernel itself has a stable interface.

Again, you are trying to pretend not to notice the common understanding and the use of the word, while pulling out some definition nobody cares about.

Yes, technically, Linux is a kernel project. But, most time the word is used to designate the whole operating system (which annoys people who like to be precise, but it's also clear as day how OP meant to use the word, and you swapping the meaning of the word OP used for something that's convenient to you to make a useless contrarian point is just an example of bad discussion).

This is simply false. The Linux maintainers have little idea of how different libc implementers expose the interface they provide, and there are non-C languages using those ABIs as well. There is also full documentation for how to access any piece of ABI that Linux exposes without using C.

For example, here is a site that documents all Linux syscalls on x86_64, with the exact registers that they read their arguments from, and the registers they write their results in:

https://filippo.io/linux-syscall-table/

> Linux maintainers have little idea of how different libc implementers expose the interface they provide

This is literally false. A huge chunk of discussion on kernel mailing lists is exactly about this subject.

And, again. When OP used the word "Linux" they meant the entire operating system. The fact that this is also the name of the kernel project is irrelevant. Perhaps OP should've written "GNU/Linux" to satisfy mindless bureaucrats, but, I guess, OP hoped that this wouldn't be necessary.

OP explicitly talks about the system interfaces - i.e. the kernel. I don't see any sign that they are talking about the whole OS. In fact, if they were talking about the whole OS, the post would be nonsensical: any OS has a userspace implemented in some language, so any OS is 'pushing a language' in this limited sense, by definition.

Either way, the OP is clearly confused about what Linux-the-kernel provides vs Linux-the-OS. Their example of async IO is nonsense - async IO is built into the kernel itself, as are threads (which are not even available in libc, at least until very recently).

I will admit that I was "greatly exaggerating" (read: lying) when claiming that kernel maintainers don't know/care how libc uses their API. But the point is that, while the needs of libc obviously inform their designs, they are not directly writing or maintaining it, unlike virtually all other mainstream OSs.

Linux is not exclusively GNU/Linux. For example, Musl/Linux (eg. Alpine Linux) and Android/Linux are widespread. The Linux ABI is unchanged.

Legitimate Linux applications are written in Go all the time. Linux applications are often written in Rust and use the Linux ABI without going through any libc. They seem to be doing mighty fine in terms of "being Linux".

This sounds like some variant of the True Scotsman fallacy.

Wow, this is a third commenter who didn't bother to read what OP wrote.

Come on! OP meant the whole OS, not the kernel project. How is this not obvious?

Reply on news.ycombinator.com