From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933112AbXCHTV6 (ORCPT ); Thu, 8 Mar 2007 14:21:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S933104AbXCHTV5 (ORCPT ); Thu, 8 Mar 2007 14:21:57 -0500 Received: from x35.xmailserver.org ([64.71.152.41]:43861 "EHLO x35.xmailserver.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933112AbXCHTV4 (ORCPT ); Thu, 8 Mar 2007 14:21:56 -0500 X-AuthUser: davidel@xmailserver.org Date: Thu, 8 Mar 2007 11:21:18 -0800 (PST) From: Davide Libenzi X-X-Sender: davide@alien.or.mcafeemobile.com To: Linus Torvalds cc: "David M. Lloyd" , Linux Kernel Mailing List , Andrew Morton Subject: Re: [patch 2/5] signalfd v2 - signalfd core ... In-Reply-To: Message-ID: References: <1173364264.6891.3.camel@localhost> X-GPG-FINGRPRINT: CFAE 5BEE FD36 F65E E640 56FE 0974 BF23 270F 474E X-GPG-PUBLIC_KEY: http://www.xmailserver.org/davidel.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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