
Glibc and the kernel user-space API - Tsiolkovsky
http://lwn.net/Articles/534682/
======
revelation
Classic drepper.

 _Theres a syscall here that maybe the layer between OS and program should
expose_

\- _Never_

~~~
DrJokepu
Didn't Ulrich Drepper retire from glibc development quite a while ago?

~~~
revelation
Yes, but I wasn't so much conjuring up his response, I'm quoting him directly
from the linked bug report :)

------
g3orge
I always wanted to say that lwn's effort to write good articles (like this
one) is shadowed by their weak website. There isn't for example an index of
similar articles like this one or introductions to various kernel
modules/structures. Maybe everyone but me can find them.

~~~
corbet
LWN kernel index at <https://lwn.net/Kernel/Index/>

Yes, the LWN site needs a lot of work. It's just hard to take the time to do
that at the expense of the content itself, but some things are in the
works...slowly...

~~~
g3orge
ok, thanks for the answer. btw, which kernel development book are you
currently suggesting??

~~~
corbet
Linux Device Drivers, of course!

Love's "Linux Kernel Development" is less obsolete currently, but I do still
think that LDD has a lot of useful information not found elsewhere. Available
in all the usual places or downloadable from <http://lwn.net/Kernel/LDD3/>

------
planckscnst
I like the idea of a header file with macros distributed with the kernel for
providing basic syscall functions. Is there any reason that couldn't work?

~~~
JoachimSchipper
Type-safety is hard with macros; you can't use a macro as a function pointer,
for the obvious reason that it's not a function; such macros would tend to
trample all over libc functionality, and glibc is not the only libc; the
kernel and userland should arguably be separate.

It wouldn't be too hard to create (generate) a "libwrapsyscall" that just
provided syscalls; if this is worth doing, it's worth doing properly.

~~~
throwaway54-762
How about 'static inline' functions distributed along with the libc header
files? You get type / number of arguments correctness and no ABI bloat, at the
cost of having (minimal) code in header files and per-object code duplication
(possibly solved by an intelligent cc/ld).

