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

Linus Torvalds
2007-03-10T22:42:11Z

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