lkml.org 
[lkml]   [2007]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 2/5] signalfd v2 - signalfd core ...


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

\
 
 \ /
  Last update: 2007-03-08 18:19    [W:0.160 / U:1.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site