| |||||||||||||
timerfd() and system call reviewtimerfd() and system call reviewPosted Aug 15, 2007 1:58 UTC (Wed) by mkerrisk (subscriber, #1978)Parent article: timerfd() and system call review Jon, thanks for the article! One point not made in the article is that in 2.6.22, the timerfd() API is broken (this I also discovered while working on the man page). In 2.6.22, it was intended that read() from a timerfd() file descriptor would return a 4-byte value, but a bug meant that only the least significant byte was returned. So the 2.6.22 interface is in any case unusable. (The fix for this problem went in with the switch to 8-byte reads.) If the kernel community were to resolve that it would not merge user-space API features in the absence of complete documentation, it might just provide the necessary incentive to get that last review pass done. Given the number of bugs and interface problems I've noticed while developing on man pages, I think this would be a hugely effective step. This will also be the subject of a presentation that I'll be making at linuxconf.eu, which precedes this year's Kernel Summit. Arnd Bergmann will cover some related ground at the conference talking about How to not invent kernel interfaces.
(Log in to post comments)
timerfd() and system call review Posted Aug 15, 2007 16:45 UTC (Wed) by davecb (subscriber, #1574) [Link] The Multicians did the whole mutation thing somewhatbetter than we do in the Unix world... they tended to document first, by writing white papers to get their algorithms discussed.
After they delivered,they then froze the parameter
I've used the same trick on Unix/Linux to avoid having to
--dave
|
|||||||||||||