Re: [PATCH - 2.6.15-rc5-mm3] Allow sysfs attribute files to be pollable.

Maneesh Soni
2005-12-22T07:08:07Z

On Thu, Dec 22, 2005 at 05:02:02PM +1100, Neil Brown wrote:
> On Thursday December 22, maneesh@in.ibm.com wrote:
> > On Thu, Dec 22, 2005 at 02:43:12PM +1100, Neil Brown wrote:
> > > You don't have to read the contents unless you want to know what is in
> > > the file. You could just open the file and call 'poll' and wait for
> > > it to tell you something has happened. However this isn't likely to
> > > be really useful.
> > > It isn't the 'something has happened' event that is particularly
> > > interesting. It is the 'the state is now X' information that is
> > > interesting.
> > > So you read the file to find out what the state is. If that isn't the
> > > state you were looking for (or if you have finished responding to that
> > > state), you poll/select, and then try again.
> > >
> >
> > ok.. that makes sense. But in this case [open() and then poll()], should
> > buffer->event() be initialized in sysfs_open()-->check_perm(), instead
> > of fill_read_buffer() ? I think this scheme should work for [open(), read()
> > and then poll()] also.
>
> We are definitely using poll in a non-standard way as it is generally
> for "you can read now" or "you can write now", and we are (ab)using it
> to say "there is new information". Note that this is essentially
> copying the semantics of 'poll' on /proc/mounts.
>
> I would see poll returning as meaning "there is state information that
> you haven't read".
>
> When you first open the file, you haven't read anything, so poll
> should return immediately - which it currently does.

If the current patch already follows the semantics you just
described (ie if polled right after open, return immediately)
then no problem.

> After you read something, poll won't return again until there is
> something new to be read.
>
> I think this is probably the best semantics, but if you try hard you
> might be able to convince me otherwise...
>
> >
> > But how about the other rule, ie once woken-up the user has to close,
> > re-open and re-read the file. Can this also be avoided, as probably this is also
> > not poll semantics?
>
> This semantic is part of sysfs. The way sysfs currently works, you
> open a file, and read it, and that is the only value you see. If you
> rewind and read again, you still get the old value, even if it
> "should" have changed. The value is cached and the cache is never
> refreshed.
>
> sysfs could be changed to flush the cache on rewind, but I don't know
> that it is worth it. If it was changed, the poll functionality would
> automatically do the right thing.
>

IMHO, it is worthy enough if it can allow "poll" to have usual semantics.

Thanks
Maneesh

--
Maneesh Soni
Linux Technology Center,
IBM India Software Labs,
Bangalore, India
email: maneesh@in.ibm.com
Phone: 91-80-25044990