On Thu, Dec 22, 2005 at 05:02:02PM +1100, Neil Brown wrote:
> On Thursday December 22, [email protected] 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: [email protected]
Phone: 91-80-25044990
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
