Filesystem-oriented flags: sad, messy and not going away

Posted Mar 17, 2020 9:51 UTC (Tue) by smurf (subscriber, #17840)
In reply to: Filesystem-oriented flags: sad, messy and not going away by josh
Parent article: Filesystem-oriented flags: sad, messy and not going away

This means that BSD's libc is tied to the kernel. Linux' libc is not.

A corollary is that statically-linked programs may or may not continue to work when you update your kernel, a notion which Linus emphatically rejects.

Filesystem-oriented flags: sad, messy and not going away

Posted Mar 17, 2020 10:25 UTC (Tue) by josh (subscriber, #17465) [Link]

I agree, and I prefer the Linux approach.

That said, it'd be interesting if we had a slightly more extensible syscall layer that could tell when an argument was passed or not passed, which would allow existing existing syscalls without having to create new ones.

It's looking increasingly like io_uring might be that extensible syscall layer.

Filesystem-oriented flags: sad, messy and not going away

Posted Mar 19, 2020 20:55 UTC (Thu) by BenHutchings (subscriber, #37955) [Link] (1 responses)

Indeed, there is no such thing as "Linux's libc". There's glibc, bionic, uclibc, musl, klibc, and at least one language run-time (Go) that doesn't depend on a C library.

Filesystem-oriented flags: sad, messy and not going away

Posted Mar 23, 2020 15:27 UTC (Mon) by gray_-_wolf (subscriber, #131074) [Link]

> least one language run-time (Go) that doesn't depend on a C library.

sometimes... would be nice if it never did but that is sadly not the case :/