Re: sending signals from xdd's

[bousch@topo.matups.fr (Thierry Bousch)]

Hello Kai,

> Usually Unixes do this by
> 1) sending this sockets owner a SIGURG signal and
> 2) waking up any processes seleting for exceptional conditions
>    on this socket.
> 
> The 1st would require a device driver to be able to send signals
> to ANY process, even if the current process' effective UID is
> not zero and different from the effective UID of the process that
> should be signaled.

This is very analogous to a serial driver, which must send a SIGHUP signal to
the process group controlled by this device.

> Currently the only possibility I see to do the 1st is to fork a
> new process (much like minixfs and modm0dev do) that is used to
> send signals.

It seems mandatory, indeed: if no process does I/O on the socket, the
device driver functions will never be called, so you can't rely on these
functions to post signals. Signals should be posted asynchronously, by
another thread.

> Is there another way (without a different process) to signal
> different processes from a device driver?
> 
> Perhaps (as Juergen suggested some time ago) post_sig() should be
> made available for device drivers through struct kerinfo?

While it would be a Good Thing, it would not solve the problem indicated
before, i.e. you still need another thread. But it would have the great
advantage of allowing this thread to execute in kernel mode, so
addroottimeout() would be usable...

Thierry.