On Tue, 23 Oct 2001, Manfred Spraul wrote:
> From: "Richard B. Johnson" <root@chaos.analogic.com>
> >
> > In this module, there isn't any read() or write() event that can
> > clear the poll mask. Instead, the sole purpose of poll is to tell
> > the user-mode caller that there is new status available as a result
> > of an interrupt. This is a module that controls a motor. It runs
> > <forever> on its own. It gets new parameters via an ioctl(). It
> > reports exceptions (like overload conditions) using the poll
> > mechanism.
> >
> > The caller reads the cached status via an ioctl(). Any caller sleeping
> > in poll must be awakened as a result of the interrupt event. Any caller
> > can read the cached status at any time. If this was allowed to
> > clear the poll mask, only one caller would be awakened.
> >
> Ugh.
> ->poll must never change any state. The kernel is free to call poll
> multiple times (common are once, twice and three times).
That's the problem. It calls poll even when there is not any user-mode
select/poll active.
>
> Can you use a per-filp pollmask?
Yes. You've got it. Private data is a place to put the per-process
poll mask.
> * remove poll_active
> * remove poll_mask
Yes.
> * add event counters for every possible event.
> poll_count_POLLIN, poll_count_POLLOUT, etc.
> * interrupt handler increases the counter.
> * ioctl() copies the value of the counters into
> filp->private_data->event_handled_POLL{IN,OUT}
> * poll sets the pollmask if
> filp->private_data->event_seen != info->poll_count
>
Yes. May not actually need counters because each interrupt
will cache a status that can be read by anybody.
The struct file_pointer.private_data is the savior.
> If filps (file descriptors) are shared between apps, then I have no
> idea how to fix your design.
>
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 23 2001 - 21:00:40 EST