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

[Greg KH]

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?

> You can't claim that this has never been done (e.g. KERNEL_HAS_O_DIRECT,
> KERNEL_HAS_DIRECT_FILEIO in 2.4 kernels).

That was because of the backport mess that 2.4 went through and vendor
kernels, right?

> 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?

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

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?

thanks,

greg k-h
-
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/