recommended method for hardware to report events to userspace?

recommended method for hardware to report events to userspace?

[Chris Friesen]

I'm doing some work on a SONET PHY and I was wondering what the recommended
method is for asynchronously reporting events to userspace.

I have some non-critical events (correctable ecc errors, etc) that I poll every
once in a while, but there are some critical events (loss of signal, for
instance) that I want to report immediately.

What is the usual way of doing this?  I see three possibilities: 1) the
userspace app could register its pid with the driver using ioctl() and on a
fault the interrupt handler in the driver could fire off a signal to the
registered pids to alert them that something happened, at which point they do
another ioctl() to find out exactly what it was,  2) use netlink to provide a
socket-based notification of what happened,  3) provide a file descriptor that
becomes readable when an event happens.

What's the Right Thing to do here?


Thanks,
Chris

-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: recommended method for hardware to report events to userspace?

[Tommy Reynolds]

Uttered "Chris Friesen" <cfriesen@nortelnetworks.com>, spoke thus:

> I'm doing some work on a SONET PHY and I was wondering what the recommended
> method is for asynchronously reporting events to userspace.
> 
> I have some non-critical events (correctable ecc errors, etc) that I poll
> every once in a while, but there are some critical events (loss of signal, for
> instance) that I want to report immediately.
> 
> What is the usual way of doing this?  I see three possibilities: 1) the
> userspace app could register its pid with the driver using ioctl() and on a
> fault the interrupt handler in the driver could fire off a signal to the
> registered pids to alert them that something happened, at which point they do
> another ioctl() to find out exactly what it was,  2) use netlink to provide a
> socket-based notification of what happened,  3) provide a file descriptor that
> becomes readable when an event happens.
> 
> What's the Right Thing to do here?

There's no One Right Way to do this.  Here's my suggested feature
hierarchy:

1) Provide a "/proc" file system entry so humans can easily see your
driver's status.  It's easy to make a simple read-only "/proc" file.

2) Implement a "poll" method in your device driver that simply blocks
until one of your anomalous events occurs.  Applications can then do
a standard select(2) system call to detect these events.  Select(2)
is quite efficient.  After the select(2) returns, then a simple
read(2) could get the data.

3) Implement a "mmap" method in your device driver so that
applications could just map in a status buffer.

4) You could use signals, but these take more handshaking
infrastructure via ioctl's between the driver and applications than
do these other suggestions.