Re: [patch 2/5] signalfd v2 - signalfd core ...

[Kent Overstreet]

On 3/8/07, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> Which is why you introduced a new system call, but that leads to all the
> problems with the file descriptor no longer being *usable*.
>
> Think scripts. It's easy to do reads in perl scripts, and parse the
> output. In contrast, making perl use a new system call is quite
> challenging.

If you're going to allow reads from the fd, then it makes sense to let processes
get the fd by opening a file; if you've got to call siginfo_create()
or what have
you, the fact that you can do reads isn't terribly useful to perl or
what have you.

Inotify even makes you get events with read() today; but you have to use system
calls to get the fd and to send events (inotify_add_watch, inotify_rm_watch),
which is something I've never understood.

It would, to me, be very cool if everything that was a stream of bytes
really was
a file; this is something I've always thought plan 9 got very right. Epoll and
inotify could work this way, and I'm sure there's others I'm forgetting.

If people are interested in this sort of thing, I'll start working on
a patch. Are there
any thoughts on where these sorts of pseudodevices should be these days?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/