On Thu, 8 Mar 2007, Davide Libenzi wrote:
>
> The reason for the special function, was not to provide a non-blocking
> behaviour with zero timeout (that just a side effect), but to read the
> siginfo. I was all about using read(2) (and v1 used it), but when you have
> to transfer complex structures over it, it becomes hell. How do you
> cleanly compat over a f_op->read callback for example?
I agree that it gets a bit "interesting", and one option might be that the
"read()" interface just gets the signal number and the minimal siginfo
information, which is, after all, what 99% of all apps actually care
about.
But "siginfo_t" is really a *horrible* structure. Nobody sane should ever
use siginfo_t, and the designer of that thing was so high on LSD that it's
not even funny. Re-using fields in a union? Values that depend on other
bits in the thing in random manners?
In other words, I bet that we could just make it a *lot* better by making
the read structure be:
- 16 4-byte fields (fixed 64-byte packet), where each field is an
uint32_t (we could even do it in network byte order if we care and if
you want to just pipe the information from one machine to another, but
that sounds a bit excessive ;)
- Just put the fields people actually use at fixed offsets: si_signo,
si_errno, si_pid, si_uid, si_band, si_fd.
- that still leaves room for the other cases if anybody ever wants them
(but I doubt it - things like si_addr are really only useful for
synchronous signals that are actually done as *signals*, since you
cannot defer a SIGBUS/SIGSEGV/SIGILL *anyway*).
So I bet 99% of users actually just want si_signo, while some small subset
might want the SIGCHLD info and some of the special cases (eg we migth
want to add si_addr as a 64-bit thing just because the USB stack sends a
SI_ASYNCIO thing for completed URB's, so a libusb might want it, but
that's probably the only such user).
And it would be *cleaner* than the mess that is siginfo_t..
(I realize that siginfo_t is ugly because it built up over time, using the
same buffer for many different things. I'm just saying that we can
probably do better by *not* using it, and just laying things out in a
cleaner manner to begin with, which also solves any compatibility issues)
Linus
-
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/
