[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9828.1284565136@localhost>
Date: Wed, 15 Sep 2010 11:38:56 -0400
From: Valdis.Kletnieks@...edu
To: Arnd Bergmann <arnd@...db.de>
Cc: linux-kernel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>,
Christoph Hellwig <hch@...radead.org>,
David Airlie <airlied@...ux.ie>,
dri-devel@...ts.freedesktop.org, Jeremy Kerr <jk@...abs.org>,
"John W. Linville" <linville@...driver.com>,
Julia Lawall <julia@...u.dk>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-fsdevel@...r.kernel.org, linux-omap@...r.kernel.org,
linuxppc-dev@...abs.org, linux-wireless@...r.kernel.org,
netdev@...r.kernel.org, Samuel Ortiz <samuel@...tiz.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Tony Lindgren <tony@...mide.com>
Subject: Re: [PATCH 00/15] change default_llseek action
On Tue, 14 Sep 2010 22:22:28 +0200, Arnd Bergmann said:
> This changes *all* instances of struct file_operations in
> the kernel to have a .llseek operation and then changes
> the default to no_llseek, which returns -ESPIPE, which
> is what we had decided some time ago in a discussion
> with Christoph Hellwig.
I don't suppose there's any clean way to throw a build error or a
printk_on_once() or something if we encounter an unconverted 'struct
file_operations', is there? I have this creeping fear that this patch will go
upstream during the merge window - as will 12 new staging/ drivers from authors
who didn't get the memo yet.
Other than the "missed converting a new usage" issue, it looks OK to me.
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists