[nathanw]

>> - They all send the same signal, but with a magic identifier
>>    somewhere in the stuff that gets passed to the signal handler.
> You mean, the signal "code" parameter, where we already pass
> auxiliary signal information (albeit only for traps)?

Probably.  Alternatively, we could add hidden stuff at the end of the
struct sigcontext, stuff which is set on handler entry and ignored on
handler exit.  After all, using the code allows us only an int of
information, whereas growing sigcontext allows us a more or less
unlimited amount of stuff.  (Arguably, storing stuff at (void *)(scp+1)
is even worse magic than spinning off a process for the purpose.)

>> - They don't kick init directly; instead, they cause the kernel to
>>    hand-craft a new process, which execs an executable appropriate
>>    to the key hit.
> Too Much Magic.

Possibly, possibly.  It's certainly a possibility; it wouldn't even be
very hard to do.  Whether it's a good idea for this application...well,
given the reaction, I'd say "quite likely not", if only to avoid
disturbing a bunch of people.

> Even one hand-crafted process has always felt like too many.

Kinda unavoidable, though.  But with kernel threads for things like the
pagedaemon and ioflush, there's no reason one more kernel thread
couldn't be created, and it then exec a user-land program....

[greywolf]

>> Conceptually, I see nothing wrong with it.  I do think it's a bad
>> idea to assign a separate signal to each of three keys like this;
>> the signal space is very small and this hijacks a nontrivial
>> fraction of it.
> What other conditions are we planning to build into init?

Planning to?  None, presumably.  But I really hesitate to cut off room
for future innovation.  I have no clue what clever idea someone will
have a year or two from now that calls for another communication
channel to init.

>> - They all send the same signal, but with a magic identifier
>>    somewhere in the stuff that gets passed to the signal handler.
> That'd be interesting considering I don't think that external
> processes can pass data through that way.  [and in a subsequent
> message]  After reading up on kill and company, I cannot see how an
> external process can send anything else down that pipe!

As nathanw pointed out, it's the kernel itself, in response to a magic
hardware event (ctl-alt-del, or power-button, or whatever) sending the
signal, not a userland process.  Since other processes can't do it,
that means stuff communicated that way is unforgeable (which is
arguably a Good Thing for this application).

>> - They don't actually send a signal at all; init has a descriptor
>>    open (on /dev/hotkeys, perhaps, or maybe an AF_INIT socket), and
>>    magic keystrokes appear as input on that fd.
> That'd have to be a socket that only the kernel knew about.

Why?  init may not be the only process that has occasion to field
hotkeys; a method that can be reused might not be a bad thing.

>> - They don't kick init directly; instead, they cause the kernel to
>>    hand-craft a new process, [...]
> *shudder*.  For some reason, that looks _really_ evil.

Nathan seems to agree with you...I wonder why it doesn't look so evil
to me.  Perhaps I'm evil too. ]:-¦

> I'd opt for a socket or some other hidden channel.

I've been thinking about /dev/hotkeys vs AF_INIT sockets and I think
the latter is better for this application.

But another thought comes to mind.  I saw rumblings about a generalized
event mechanism - could this be worked into that?

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B