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

From: Marko Macek
Date: Thu Mar 08 2007 - 16:25:56 EST


Linus Torvalds wrote:

On Thu, 8 Mar 2007, Davide Libenzi wrote:
So, to cut it short, I can do the pseudo-siginfo read(2), but I don't like it too much (little, actually). The siginfo, as bad as it is, is a standard used in many POSIX APIs (hence even in kernel), and IMO if we want to send that back, a struct siginfo should be.
No?

I think it's perfectly fine if you make it "struct siginfo" (even though I think it's a singularly ugly struct). It's just that then you'd have to make your read() know whether it's a compat-read or not, which you really can't.

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.

Probably, but someone will have to add the 'signalfd' system call anyway.

And *that* is why "everything is a stream of bytes" is so important. You don't know where the file descriptor has been, or who uses it. Special system calls for special file descriptors are just *wrong*.

After all, that's why we'd have a signalfd() in the first place: exactly so that you do *not* have to use special system calls, but can just pass it on to any event waiting mechanism like select, poll, epoll. The same is just *even*more*true* when it comes to reading the data!

The problem with read() returning arbitrary unstructured data is that there is hard to do versioning/extensibility, since the userspace can't specify the requested/expected format. The only way it could be done is by the (nbytes) parameter to read() which is not very nice (and useless for scripts).

This is the same problem that makes sysfs/procfs fragile unless the
file format is very well specified for extensibility (and it's easy to
f-it up, since there seems to be little consistency there... using
the XML horror would actually be an improvement). Breaking sysfs/procfs
might be acceptable once every few years, but signal handling will be
part of every application event loop and there is no room for breaking anything.

(although, one could to the versioning the ugly way by creating the new 'signalfd' syscall instead).

I'd say: make read() return the signal number (probably as 4-byte int, in network byte order), but for everything else, use the system call.

Mark

P.S. I'm currently worried if the fact that FUTEX_FD is being deprecated is a problem :)

-
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/