[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091021214537.GD4880@nowhere>
Date: Wed, 21 Oct 2009 23:45:38 +0200
From: Frederic Weisbecker <fweisbec@...il.com>
To: John Kacur <jkacur@...hat.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
Jonathan Corbet <corbet@....net>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
linuxppc-dev@...abs.org, Alan Cox <alan@...rguk.ukuu.org.uk>,
Arnd Bergmann <arndbergmann@...glemail.com>
Subject: Re: [PATCH] macintosh: Explicitly set llseek to no_llseek in
ans-lcd
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists