Hi,

this sounds quiet right for me, how about making a device like
/dev/specialkeys for thos actions.
This would give a clean kernel interface and anyone who wants to use such
features could run a deamon listening to the device and doing the actions?
(It might be wrong)

lars


"Nathan J. Williams" wrote:

> Greywolf <greywolf@starwolf.com> writes:
>
> > # 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.
>
> Mmph. I think we crossed wires somewhere.
>
> People have been talking about init(8) doing the actual powerbutton
> stuff, and this particular side-topic was about how the kernel would
> inform init that one of the Magic Buttons was pressed, so that it
> could do its userland work.
>
> > 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.
>
> I agree that that's ugly, but I don't think it's what anyone proposed.
>
> It's more like:
>
> 1) Kernel input device driver notices a Magic Button was pressed.
> 2) Kernel tells init about the Magic Button.
> 3) Init chooses an action based on a configuration file.
> 4) Init executes the action.
>
> The signal/sigcode, socket, and device stuff were all in the realm of
> making (2) happen.
>
>         - Nathan