The tty driver is a case in point: many struct file's may point to a
single struct tty_struct. In the case of the tty driver example, when
the I/O channel changes state, processes sleeping on a poll may need
to be woken up. So the driver would need to maintain a linked list of
struct file's (inside the struct tty_struct) and iterate over this
list whenever the "poll_events" field in each file needs to updated.
My point is that while the original scheme I proposed may well work,
it involves some extra effort on the part of driver writers. So, as an
alternative, I propose that the is only one new field added to struct
file, called "poll_ctrl" or something like that. This points to a
new structure (struct poll_control) which contains a "poll_events"
mask, a "poll_queue" field which is a pointer to a wait queue, and a
pointer to a linked list of struct file's or an array of them.
The struct poll_control is stored in the driver-specific structure
(like struct tty_struct) and is simply pointed to by the "poll_ctrl"
field in struct file.
Utility routines would be provided to add a struct file pointer to a
struct poll_control and to notify any polling processes of state
changes in the I/O channel.
So, the tty driver would do something like:
poll_init_control(&tty->poll);
when struct_tty has to be initialised.
Then, when a new struct file opens on the tty device:
poll_add_file(&tty->poll, filp);
And, when it comes time to wake up polling processes:
poll_notify(&tty->poll, POLLNVAL);
that's the lazy way which requires poll_notify() to call the poll
indirect function for the first file with a non-NULL poll f_ops
field. The better way is:
poll_notify(&tty->poll, (tty->ldisc.poll)(tty, filp, NULL));
or some such.
And when closing a file, a driver doesn't need to do anything, because
it's automagically taken care of.
So, what do people think? I'd hope that this would ease the transition
to the new polling mechanism for driver writers.
Regards,
Richard....