On Fri, Nov 01, 2013 at 11:08:00AM -0400, Tejun Heo wrote:
> Hello, Greg.
>
> On Fri, Nov 01, 2013 at 08:04:48AM -0700, Greg Kroah-Hartman wrote:
> > > @@ -800,7 +800,7 @@ EXPORT_SYMBOL_GPL(sysfs_notify);
> > > const struct file_operations sysfs_file_operations = {
> > > .read = seq_read,
> > > .write = sysfs_write_file,
> > > - .llseek = seq_lseek,
> > > + .llseek = generic_file_llseek,
> >
> > Does that mean that seq_lseek can't handle SEEK_END? Shouldn't we fix
> > that instead?
>
> As the files are dynamic, seq_file has no way of knowing whether the
> file is gonna end at all. It's perfectly valid to have an infinite
> file. The only benefits of using seq_lseek() instead of
> generic_file_llseek() are
>
> * Early failure. For whatever reason, traversing to certain file
> position should fail, seq_lseek() will report such failure on
> seek(2) instead of the following read/write operations.
>
> * EOF detection. While SEEK_END is not supported, SEEK_SET/CUR +
> large offset can be used to detect eof - eof at the time of the last
> seek anyway as the file size may change dynamically.
>
> I don't think either would matter for sysfs or for prospect kernfs
> users and sticking with genefic_file_llseek() should be fine.
Ok, you are right, that makes sense as sysfs files do have an end,
although it seems odd that userspace would care to try to find it and
not just do a seek to the start of the file.
Fun userspace oddities, just when you thought you had seen it all...
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
