[PATCH] macintosh: Explicitly set llseek to no_llseek in ans-lcd

Frederic Weisbecker fweisbec at gmail.com
Thu Oct 22 08:45:38 EST 2009

On Wed, Oct 21, 2009 at 11:33:17PM +0200, John Kacur wrote:
> > Should we better pushdown default_llseek to every to every
> > file operations that don't implement llseek?
> > I don't know how many of them don't implement llseek() though.
> > 
> > That said we can't continue anymore with this default attribution
> > of default_llseek() on new fops.
> > 
> If you don't explicitly set it to no_llseek, you automatically get the
> default_llseek, which uses the BKL. So if your driver doesn't need it, it 
> is best to explicitly set it to no_llseek.

Sure, that's the right thing to do.

> There is also a generic_file_llseek_unlocked, somewhat analogous to the 
> unlocked_ioctls that you can use if you don't need to provide a full 
> llseek yourself.

No problem with that. Setting no_llseek or generic_file_llseek_unlocked,
depending on the context is the right thing to do.

What I'm wondering about concerns the future code that will have
no llsek() implemented in their fops.

We can't continue to use default_llseek() for future code unless we
want to continue these post reviews and fixes forever.

More information about the Linuxppc-dev mailing list