Re: [PATCH] fix: macros to detect existance of unlocked_ioctl and compat_ioctl

[Takashi Iwai <tiwai@xxxxxxx>]

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@xxxxxxxxxxxxxx>
> > > > 
> > > > 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/