recommended method for hardware to report events to userspace?
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
Signature · 4 lines
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: [email protected]
Uttered "Chris Friesen" <[email protected]>, spoke thus:
Quoted 15 lines
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 anotherioctl()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.
Quoted 1 line
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.