Messages in this thread | | | Date | Fri, 9 Mar 2007 11:22:27 -0900 | From | "Kent Overstreet" <> | Subject | Re: [patch 2/5] signalfd v2 - signalfd core ... |
| |
On 3/8/07, Linus Torvalds <torvalds@linux-foundation.org> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |