Date: Mon, 15 Nov 1999 15:30:27 +0100 From: Marcel Moolenaar <marcel@scc.nl> To: arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/include signal.h Message-ID: <38301903.52DDD6C4@scc.nl> References: <382E8A1B.B7D9B7F0@scc.nl>, <19991115130854.A28445@cons.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Martin Cracauer wrote: > > > > > I disagree. Signal handlers don't use context information for (wild > > > > guess) 99.9% of the time. Bloating signalling definitions with details > > > > of the many different hardware configurations (even within a single > > > > architecture) is not the way to go. > > > > > > Maybe we have a different definition of "bloat", but since the size is > > > the same, this doesn't count as "bloat for me. > > > > The bloat is in what you get when you include <signal.h> > > OK, you're speaking compile-time bloat here. > > What I'm trying to do is to access members of a data struct by reusing > a struct definition that is already in our tree, and not requireing > the user to access the members by couting bytes and then cast. > > That not bloat, that's moving struct definitions to where they are > needed. But not *when* they are needed. As I said, only a very small number of applications actually need to use the context information passed on to the signal handler. I think it's better that these applications need to include another header for the in-depth definitions than that every C-source file that include signal.h gets poluted with these definitions. > > > When I implemented SA_SIGINFO, you could get it in a type-save way as > > > a member of the second argument. This capability has been removed by > > > your newer signal changes. > > > > Yes, because ucontext_t is not part of siginfo_t and adding it there > > only creates unnecessary dependencies and pitfalls. Not to mention the > > size increase and the shear unportability of the approach. > > Sorry, you are wrong here. It doesn't increase the amount of data that > is stored or copies for signal handlers. The sigframe is not increased by it, but that's the only place. > > You don't want to implement RT signals with a bloated siginfo_t... > > If the RT signals don't use a struct sigcontext at all (and I mean, > the kernel implementation doesn't need one when sending the signal and > returing from it, no matter whether the application's signal handler > can access it), then you can omit it. There's no need for every global and/or local declaration of siginfo_t to carry struct sigcontext. Neither do you want such a bloated structure passed as the argument of the RT signal syscalls back to the kernel. Especially when you're thinking of increasing sigcontext to about .5KB. It doesn't belong there. It shouldn't be there. > > A change in how the state is saved would then automaticly result in an > > interface change while this should not be the case (I should know, I did > > exactly the same thing :-) > > I don't understand why the fact the the description might not useful > in the emulator case prevents us from securing the case for the > hardware FPU case. Are you saying that you want a FP state structure that matches the hardware and is indifferent to how emulators store their state? This means you present a structure that only makes sense in a single case. That's even worse than using an array in all cases. > > If you refer to the general case here, then also do it for the saved > > state. In the general case, that may be very incompatible for each > > different FPU and or emulator, which is not limited to what we have now. > > We're talking different levels of generality here. I'm talking about > more extensions to the "things" that a signal handler gets passed. You're right. I'm not :-) -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38301903.52DDD6C4>