On Sun, 14 Jan 2001, der Mouse wrote:

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

Right, right -- missed the "from the kernel" thing, sorry.

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

Yep.

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

Wouldn't that involve some major rewhacking on the process scheduling
code as well?

# 					der Mouse

				--*greywolf;
--
"Never mind the bollocks, here's BSD!"