timerfd() and system call review [LWN.net]

timerfd() and system call review

Posted Aug 17, 2007 17:40 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

I agree. If you have a "We're not committed to this and don't stand behind it yet" status, things stay in that status a long time and then there's no distinction between function in that status and not.

I think it should be like the 5-second rule for reclaiming food dropped on the floor. You have one release to change your mind and redo a user interface before it becomes set in stone.

The effectiveness of that would depend entirely upon how well the rule can be communicated to users.

timerfd() and system call review

Posted Aug 28, 2007 17:31 UTC (Tue) by efexis (guest, #26355) [Link]

So you have a ratification process, where the next (or next+1) release either ratifies the API and it becomes 'stable', alters it (and it remains 'experimental'), or removes it. This stops anything sitting in the experimental state for too long, as developers have to make the improvements or formalise it to keep it in the kernel.

timerfd() and system call review

Posted Aug 18, 2007 18:19 UTC (Sat) by landley (guest, #6789) [Link]

Don't confuse formalizing with automating. Adding bureaucratic
procedures to collaborative volunteer development really doesn't improve
matters. (You can't do this unless you've filled in the proper forms.
Isn't this a fun hobby?)

Having infrastructure so that something automatically times out if not
dealt with, and people can check what timeouts are pending, that might
help.

timerfd() and system call review

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

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

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.
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).
Verify that the API has been well documented, either by the developer, or by third parties (working in collaboration with the developer).

timerfd() and system call review

Posted Aug 20, 2007 5:08 UTC (Mon) by landley (guest, #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...