On Thu, 8 Mar 2007, Linus Torvalds wrote: > > > 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)
I can do that, no problem. But isn't it better to recognize that this kind of data just can't be shipped through a non compat-able function? Like, for example, the current trend to say "just use u64 for a pointer, it'll be fine". I remeber, a long time ago when the i386 architecture came out, to say "Wow! 4GB is gonna last *forever*!", let's use u32 for pointers. Well, forever is almost here in my watches. And all the userspace code using APIs assuming to cleanly store a pointer in a u32 will have to be re-factored. 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? - Davide - 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/
