| |||||||||||||
Glibc and the kernel user-space APIGlibc and the kernel user-space APIPosted Jan 30, 2013 18:09 UTC (Wed) by jwarnica (subscriber, #27492)Parent article: Glibc and the kernel user-space API
Forgive my ignorance in the details of shared objects... but why would GlibC not include these (more obscure) syscalls in some auxiliary library? One which has a disclaimer like "this is guaranteed to break, but is better than nothing, STFU".
Or maybe then the discussion would just go from "exist?", to "promote to supported?".
(Log in to post comments)
Glibc and the kernel user-space API Posted Feb 1, 2013 0:01 UTC (Fri) by wahern (subscriber, #37304) [Link]
I think the argument is that it's more trouble than it's worth. That is, more time and anxiety is spent providing the wrapper than that spent by the few people actually using the syscall writing their own wrapper. It's not so much about maintenance, but the upfront work and pile of junk wrappers.
Writing your own wrapper is utterly trivial, unless you're a masochist and are intent on supporting multi-arch systems. For syscalls like gettid, there's absolutely nothing wrong with just writing syscall(SYS_gettid). It can even be cleaner if you're writing portable apps, because you can just `#ifdef SYS_gettid', rather than testing for the existence of glibc or __linux, or having to bring autotools into the equation (if it's not already).
|
|||||||||||||