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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
