Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sat, 10 Mar 2007, Nicholas Miell wrote:
> 
> Care to elaborate on why they're a horrible crock?

It's a *classic* case of an interface that tries to do everything under 
the sun.

Here's a clue: look at any system call that takes a union as part of its 
arguments. Count them. I think we have two:
 - struct siginfo
 - struct sigevent
and they are both broken horrible interfaces where the data structures 
depend on various flags.

It's just not the UNIX system call way. And none of it really makes sense 
if you already have a file descriptor, since at that point you know what 
the notification mechanism is.

I'd actually much rather do POSIX timers the other way around: associate a 
generic notification mechanism with the file descriptor, and then 
implement posix_timer_create() on top of timerfd. Now THAT sounds like a 
clean unix-like interface ("everything is a file") and would imply that 
you'd be able to do the same kind of notification for any file descriptor, 
not just timers.

But posix timers as they are done now are just an abomination. They are 
not unix-like at all.

> And are the bugs fixed? If so, why replace them? They work now.

.. but the reason for the bugs was largely a very baroque interface, which 
didn't get fixed (because it's specified by the standard).

I'd rather have straightforward interfaces. The timerfd() one lookedalot 
more straightforward than posix timers.

(That said, using "struct itimerspec" might be a good idea. That would 
also obviate the need for TFD_TIMER_SEQ, since an itimerspec automatically 
has both "base" and "incremental" parts).

		Linus