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

[Neil Brown]

On Thursday December 22, maneesh@xxxxxxxxxx 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.
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.


Thanks again,

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/