The kernel and the C library as a single project [LWN.net]

The kernel and the C library as a single project

Posted Nov 30, 2010 21:19 UTC (Tue) by Trelane (guest, #56877)
Parent article: The kernel and the C library as a single project

Is there a particular reason new syscalls need to be in libc immediately? Why not have a different library?

to post comments

The kernel and the C library as a single project

Posted Nov 30, 2010 21:21 UTC (Tue) by Trelane (guest, #56877) [Link] (10 responses)

(as an intermediate; clearly, syscalls should eventually reside in libc)

The kernel and the C library as a single project

Posted Nov 30, 2010 21:46 UTC (Tue) by xtifr (guest, #143) [Link] (9 responses)

Should they? When I'm writing C, I'd rather write C, not some OS-specific variant. Granted, that goal's not quite achievable today, but I'd rather things get better than worse. I'd like to see the OS-specific features, like weird, non-standard syscalls, be kept in a separate library and headers so I can use them if I need them, but I'll always be aware that they are OS-specific and not portable.

Of course, in my ideal world, we all have a choice of OSes, and can pick the one that suits us best, and have the apps we need with little more than a simple recompile.

The kernel and the C library as a single project

Posted Nov 30, 2010 22:04 UTC (Tue) by Trelane (guest, #56877) [Link] (8 responses)

I'm pretty sure the proposed new syscalls are by their nature non-portable. Hence adding a new library would not be any worse in this regard (rather, it'd be even clearer that you're doing something non-portable).

The kernel and the C library as a single project

Posted Nov 30, 2010 22:09 UTC (Tue) by skitching (guest, #36856) [Link]

Sounds like a good idea to me - a "liblinux" providing linux-specific functionality.

The kernel and the C library as a single project

Posted Nov 30, 2010 22:37 UTC (Tue) by nteon (subscriber, #53899) [Link] (6 responses)

using the syscall itself would be non-portable. but libc functions can be rewritten to use a new syscall, which would give your program/lib performance improvements 'for free'. Ingo mentioned the POSIX AIO functions as an example.

The kernel and the C library as a single project

Posted Nov 30, 2010 23:15 UTC (Tue) by Trelane (guest, #56877) [Link] (1 responses)

Sure, and you could use the lib until it gets integrated into libc.

The kernel and the C library as a single project

Posted Dec 1, 2010 16:42 UTC (Wed) by busterb (subscriber, #560) [Link]

There are libraries that do this today. A couple of examples:

libpcap abstracts the OS-specific calls to setup and capture from a raw socket. It includes several variations on a theme for Linux specifically, ranging from select/read semantics to mapping a shared-memory ring buffer.

libevent abstracts OS-specific replacement syscalls for select/poll, using whatever is fastest for a particular OS.

libaio is similar, but for asynchronous IO

These libraries all present a stable ABI for apps to use, similar to libc. Having a library like this seems like the perfect incubator for new syscalls as well.

The kernel and the C library as a single project

Posted Dec 1, 2010 16:37 UTC (Wed) by nix (subscriber, #2304) [Link] (3 responses)

Yep! And the aio functions are maintained in a separate library (libaio), not in glibc. This has really helped libaio develop fast, oh, wait, no it hasn't: it languished unmaintained for years.

The kernel and the C library as a single project

Posted Dec 1, 2010 16:45 UTC (Wed) by busterb (subscriber, #560) [Link] (2 responses)

I don't think libaio failing indicates a general problem with the approach. libpcap and libevent seem to be doing well.

The kernel and the C library as a single project

Posted Dec 2, 2010 14:41 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

libpcap was also near-dead for a long, long time.

It's not a kiss of death, but it's not a magic bullet to make things instantly be well-maintained, either. :)

The kernel and the C library as a single project

Posted Jan 2, 2011 13:27 UTC (Sun) by gvy (guest, #11981) [Link]

Did it really need attention?