User: Password:
Subscribe / Log in / New account

timerfd() and system call review

timerfd() and system call review

Posted Aug 19, 2007 7:52 UTC (Sun) by mkerrisk (subscriber, #1978)
In reply to: timerfd() and system call review by landley
Parent article: timerfd() and system call review

I doubt that timeouts are enough. Too many things just get by because no-one notices (in time).

By a formalized process, I was suggesting something like a sign-off from one (or preferably more) individuals who might not necessarily be kernel developers, but must be well versed in the Unix system call APIs, who would

  1. Consider the design of the API, in particular aspects such as:
    • Generality of the design: is it too tailored towards a single purpose? could it be generalized to suit a wider range of uses?
    • Simplicity; e.g., is the API overly complex? Complexity often hints at bad design.
    • Consistency with similar APIs; e.g., if this API takes similar arguments to an existing API, does it interpret them in a similar way to that API? (This might seem obvious, but there are certainly some glaring examples where new Linux syscalls have failed to follow this simple idea.)
    • Integration with existing APIs; e.g., could this API perhaps be better written as something that leverages existing features of the existing system call API? timerfd() is an interesting case in point. One of the things I have now begun to wonder is whether it would be feasible to have tight integration of timerfd with the POSIX timers API, so that all that is required is a simplified timerfd() call that takes only a clockid argument and creates a timerfd descriptor and returns a timer_t * which is then manipulated using the traditional timer_settimer(), timer_gettimer(), etc.
  2. Verify that the API had undergone sufficient testing, either by examining the coverage of the test programs provided by the API developer, or by writing programs of their own (in fact I'd say the later is in any case necessary).
  3. Verify that the API has been well documented, either by the developer, or by third parties (working in collaboration with the developer).

(Log in to post comments)

timerfd() and system call review

Posted Aug 20, 2007 5:08 UTC (Mon) by landley (subscriber, #6789) [Link]

I could see a separate API list, for discussing JUST API issues and not
implementation, which stuff could get cc'd to the way I cc stuff to
linux-doc. (Things just get buried and lost on linux-kernel.)

But adding more layers of bureaucracy seldom improves a process, and
inflicting bureaucracy on volunteers makes them go away. (We added
signed-off-by for _tracking_ purposes, in response to a clear and present
danger the nature of which was a lawsuit.)

Adding additional layers of verification and certification before
something can be merged is never how Linux has done stuff. Linus still
accepts some patches directly, when you can get his attention...

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds