timerfd() and system call review

Posted Aug 19, 2007 7:52 UTC (Sun) by mkerrisk (subscriber, #1978) [Link]

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).