Re: [PATCH] sony_pi: Remove the BKL from sonypi_misc_open

[Christoph Hellwig <hch@infradead.org>]

On Thu, Oct 22, 2009 at 03:50:04PM +0200, Arnd Bergmann wrote:
> Is it safe to assume that file_operations without a read() or write()
> method also don't need llseek?

There are two reasons why a driver could need llseek:

 (a) it uses the file position somewhere.  Normally that's just in
     read/write, but I wouldn't be surprised if there are drivers using
     the file position somewhere in weird ioctls.
 (b) because broken userland assumes they can seek on the file
     descriptor.  For example some versions of tar expect lseek to work
     on tape devices despite them not actually using the file position
     anywere.

So the answer to your above questions is: most likely yes, but and audit
for a) should be performed.  We can't do much about (b) except for trial
and error.  Unless there are very important applications expecting to be
able to seek I think returning the correct error is more important than
having zero change in behaviour.

> Testing for S_IFREG will not work well for debugfs, which is probably
> a large number of the cases that do not want an llseek method.

Yes.  S_IFREG should be done last, and probably the real filesystem
should be converted to always have a llseek method before tackling the
mess in the synthetic filesystems.