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

[Greg KH]

On Wed, Jan 12, 2005 at 10:43:26PM +0100, Andi Kleen wrote:
> > No, we do not do that in the kernel today, and I'm pretty sure we don't
> 
> Actually we do. e.g. take a look at skbuff.h HAVE_*
> There are other examples too.
> 
> > want to start doing it (it would get _huge_ very quickly...)
> 
> I disagree since the alternative is so ugly.

But the main problem with this is, when do we start deleting the HAVE_
symbols?  After a relativly short period of time, they become useless,
as all kernels of the past year or two have that feature, and why even
test for it?

I agree, that for short term, vendor-patched kernels, it's nice to have
something like that to try to build your out-of-the-tree module.  But
move to get that module into the tree, or provide your favorite vendor
with the properly patched driver (hey, I can dream...)

And is the alternative (using autoconf to build tiny modules testing for
different features) that ugly?  Yeah, I hate autoconf too, but I thought
that work (kernel feature testing in autoconf) has already been done,
right?

> > Please don't apply this.  Remember, out-of-the-tree modules are on their
> > own.
> 
> I don't know who made this "policy", but actively sabotating or denying 
> useful facilities to free out of tree modules doesn't seem to be a 
> very wise policy to me.

I'm not trying to sabotage anything, I just don't want the maintaince of
a zillion HAVE_ macros to slowly overrun us until we drown under the
weight.  All to support some looney, ill-informed vendor that can never
get around to submitting their driver to mainline.

And as for that "policy", it's been stated in public by Andrew and
Linus and me (if I count for anything, doubtful...) a number of
documented times.

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/