On 14 Jan 2001, Nathan J. Williams wrote:

[that I wrote, which I did:]
# > 
# > After reading up on kill and company, I cannot see how an external process
# > can send anything else down that pipe!  That would really make it
# > difficult for that one to work.
# 
# It's true that other processes don't get to do that, but we're talking
# about messages communicated from the kernel. The kernel uses
# trapsignal() all the time to pass extra information about various
# things in the sigcode.

Well, yeah, but the powerbutton stuff is presumably being implemented
in userland, from the discussions I've seen.

Otherwise it's an intermodal hack to have a userland configuration
read in parameters which are going to get stuffed into kernel namespace
so it can call an exec() on it.  That's just ... I don't know, ugly,
I think, and seems like the wrong way to handle it.

Yes, signal space is limited, but we've got, what, 33 different signals
available now, most everything is ignored by init except for TSTP (which
is probably deprecated given the windowish setups most folks use), HUP
(to refresh gettys), and TERM (to go into single-user mode).  I don't
see that it uses too much space, unless, as I noted, we're planning
to play the same stupid games with init that SVRx does.

(If we're going to get twisted, we COULD have it do something with
SIGKILL and SIGSTOP, since nobody else can use them!)

#         - Nathan

				--*greywolf;
--
*BSD: preferred by Rocket Scientists and Moms!