Date: Thu, 13 Jan 2005 11:57:56 +0100
Message-ID: <s5hy8exa957.wl@alsa2.suse.de>
From: Takashi Iwai <tiwai@suse.de>
To: Greg KH <greg@kroah.com>
Cc: "Michael S. Tsirkin" <mst@mellanox.co.il>, Andrew Morton <akpm@osdl.org>,
       ak@suse.de, mingo@elte.hu, rlrevell@joe-job.com,
       linux-kernel@vger.kernel.org, pavel@suse.cz, gordon.jin@intel.com,
       VANDROVE@vc.cvut.cz
Subject: Re: [PATCH] fix: macros to detect existance of unlocked_ioctl and compat_ioctl
In-Reply-To: <20050112225819.GB14590@kroah.com>
References: <20041215065650.GM27225@wotan.suse.de>
	<20041217014345.GA11926@mellanox.co.il>
	<20050103011113.6f6c8f44.akpm@osdl.org>
	<20050105144043.GB19434@mellanox.co.il>
	<s5hd5wjybt8.wl@alsa2.suse.de>
	<20050105133448.59345b04.akpm@osdl.org>
	<20050106140636.GE25629@mellanox.co.il>
	<20050112203606.GA23307@mellanox.co.il>
	<20050112212954.GA13558@kroah.com>
	<20050112221309.GW8098@schnapps.adilger.int>
	<20050112225819.GB14590@kroah.com>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 MULE XEmacs/21.4 (patch 15) (Security Through Obscurity) (i386-suse-linux)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3225
Lines: 74

At Wed, 12 Jan 2005 14:58:19 -0800,
Greg KH wrote:
> 
> On Wed, Jan 12, 2005 at 03:13:09PM -0700, Andreas Dilger wrote:
> > On Jan 12, 2005  13:29 -0800, Greg KH wrote:
> > > On Wed, Jan 12, 2005 at 10:36:06PM +0200, Michael S. Tsirkin wrote:
> > > > To make life bearable for out-of kernel modules, the following patch
> > > > adds 2 macros so that existance of unlocked_ioctl and compat_ioctl
> > > > can be easily detected.
> > > >  
> > > > Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
> > > > 
> > > > diff -puN include/linux/fs.h~ioctl-rework include/linux/fs.h
> > > > --- 25/include/linux/fs.h~ioctl-rework	Thu Dec 16 15:48:31 2004
> > > > +++ 25-akpm/include/linux/fs.h	Thu Dec 16 15:48:31 2004
> > > > @@ -907,6 +907,12 @@ typedef struct {
> > > >  
> > > >  typedef int (*read_actor_t)(read_descriptor_t *, struct page *, unsigned long, unsigned long);
> > > >  
> > > > +/* These macros are for out of kernel modules to test that
> > > > + * the kernel supports the unlocked_ioctl and compat_ioctl
> > > > + * fields in struct file_operations. */
> > > > +#define HAVE_COMPAT_IOCTL 1
> > > > +#define HAVE_UNLOCKED_IOCTL 1
> > > 
> > > No, we do not do that in the kernel today, and I'm pretty sure we don't
> > > want to start doing it (it would get _huge_ very quickly...)
> > > 
> > > Please don't apply this.  Remember, out-of-the-tree modules are on their
> > > own.
> > 
> > Gee, thanks.  It's not like some out-of-tree code doesn't _want_ to go
> > into the core kernel, but usually the time between some code being
> > developed and when it is included is lengthy (i.e. "this feature won't
> > be accepted until lots of people use it").
> 
> I understand that, but for stuff like that, isn't it easier to just test
> for VERSION?  Or use autoconf?
> 
> > For code that needs to handle
> > multiple kernel versions this makes life far easier and doesn't actually
> > hurt anything.  It used to be that you could use LINUX_VERSION_CODE for
> > this kind of check, but that breaks down quickly with vendor kernels and
> > the long development cycle.
> 
> What long development cycle?  The out-of-the-tree stuff?  Or the kernel
> development stuff?

I guess the latter.  Imagine that the stuff already exists in mm tree 
but the merge to the maintree is delayed.  In this case,
KERNEL_VERSION check doesn't work reliably.  But, it's a rare case,
AFAIK.

> My main issue is when would we ever be able to remove such HAS macros?

Here I agree with Greg.  It'll be difficult to remove it once after
added.  Nobody knows whether the external stuff still refers to it or
not...

> And who specifically will be testing for these HAVE_COMPAT_IOCTL and
> HAVE_UNLOCKED_IOCTL macros?  Will that code make it into the main tree
> ever?  If not, why not?

ALSA, for example, still offers for 2.2, 2.4 and older 2.6 kernels.
So it requires checks for such kernel API changes.  I would do this
via autoconf without problem if HAS_* isn't introduced, though.


Takashi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/