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

[Petr Vandrovec]

On Thu, Jan 06, 2005 at 03:14:29PM +0000, Christoph Hellwig wrote:
> On Thu, Jan 06, 2005 at 04:09:42PM +0100, Andi Kleen wrote:
> > I would agree that it shouldn't be used for in tree code, but for
> > out of tree code it is rather useful. There are other such feature macros
> > for major driver interface changes too (e.g. in the network stack).
> 
> Which is the only place doing it.  We had this discussion in the past
> (lastone I revolve Greg vetoed it).  We simply shouldn't clutter our
> headers for the sake of out of tree drivers - with LINUX_VERSION_CODE
> we've already implemented a mechanism for out of tree drivers.

LINUX_VERSION_CODE never worked in last ~4 years as definite key to make
decision about supported API.  Vendors are porting stuff across releases,
there exists additional trees like -mm, -wolk, -ac, and even if you look 
at the current example with deprecating register_ioctl32_conversion you'll 
find that it does not work: 

2.6.10 kernel which presents itself as 0x02060A does have this, but 
does not have {compat,native}_ioctl.  

2.6.10-mm2 kernel, which presents itself as 0x02060A too, has 
{compat,native}_ioctl, and also has register_ioctl32_conversion.  

And there is intention to apply patch to 2.6.10-mmX which will present 
itself as 0x02060A again, will have {compat,native}_ioctl, and will either
not have register_ioctl32_conversion at all, or will produce 
unfortunate unwanted annoying warning when this function is used.

So you'll have two 2.6.10 kernels, one says that register_ioctl32_conversion is
only way to do things, and at same time it will say that register_ioctl32_conversion
is deprecated.  Strange, isn't it?  Unfortunate?  Maybe.  Can this work with
LINUX_VERSION_CODE?  Definitely not without an additional checks on other
things.

Same situation exists with pml4/pgd/pud I described in previous mail.  You have
2.6.10 with pgd only, 2.6.10-bkWhatever with pgd/pud, and 2.6.10-mmX with pml4/pgd.
This cannot be checked by LINUX_VERSION_CODE too...

Other changes usually add some #define which can be checked (like PUD_MASK or
pml4_offset), but sometime it happens that no useful macro is created and
test-compile is only way how to discover things (from past let's name epoll
change backported from 2.5.x to 2.4.x-wolk, SKAS's change to do_mmap_pgoff 
prototype living in SUSE tree for a bit, or nopage's change in prototype 
around 2.6.1).
						Best regards,
							Petr Vandrovec
							vandrove@xxxxxxxxxx
-
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/