No, what I meant by saying (perhaps in a joking manner which made it
vague) "select(2) always says YES! to all questions" is that, quoting
Single UNIX spec:
File descriptors associated with regular files always select true for
ready to read, ready to write, and error conditions.
This is why I called it "disappointing", i.e. select(2) does not do what
one might naively expect - tell me when the (regular) file has changed,
instead it always says "READY!" on all fdsets.
And rightly so - because Single UNIX v2 specs says so and specs are always
right :)
> Imagine a hardware device with a big red button on the front that is
> connected to a linux box that has a nice linux device driver. A person
> (in the real world) walks up to the device and pushes the big red
> button. On the computer, there is a user space application that dearly
> wants to know if that button ever gets pushed so it can change state and
> do the Right Thing(tm), software wise.
>
> The Linux device driver can easily be notified asyncronously when the
> button is pushed. It sits silently waiting till the button is pushed. So
> now the device driver knows something interesting has happened, but user
> space doesn't.
>
> Clearly, user space could always poll the driver -- something like:
> /* Nasty polling */
> while(1) {
> if (ioctl (fd, CHECK_IF_BUTTON_WAS_PUSHED) > 0)
> break;
> sleep(1);
> }
>
> This is obviously a bad solution. Another way to do this would be for
> user space to expect the kernel to block in the ioctl. This would also
> be bad, bad, bad, since it would create an unkillable process (ioctls
> are not interruptable last I checked).
>
> So my question boils down to: How can user space find out asyncronously
> when a button gets pushed, without resorting to ugly stuff like polling?
Ah, ok. Implement an ioctl cmd within your device driver that allows user
process to "register" itself (or another pid) as a "receiver of event
notification" ala fcntl(F_SETOWN) thing and when the event occurs make the
driver send SIGsomething (e.g. SIGUSR1) to the process, which presumably
called sigaction(2) to register a signal handler for SIGUSR1.
This is just the first thing that comes to a tired mind about to leave for
home... there must be something better but I must dash off or I'll miss my
bus :)
Regards,
Tigran.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/