On Sun, 14 Jan 2001, der Mouse wrote:

# 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.  I'd
# rather see some other way of communicating what magic button was hit.

What other conditions are we planning to build into init?  Surely we're
not going to go do the same silliness that SVRx did and start assigning
signals to run-levels (<- flame bait but not intended as such).

# I'm not sure what that way might be.  Some possibilities that come to
# mind, of varying degrees of goodness:
# 
# - 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.  Even more difficult since init cannot
tell which process kicked it...

# - 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.

# - 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.  If the executable doesn't exist, the key is
#    effectively ignored.  (This executable may, if it wants, kick init,
#    in any of numerous ways.)

*shudder*.  For some reason, that looks _really_ evil.

And I keep reading hand-craft as hand-cruft.

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


				--*greywolf;
--
*BSD, stupid.