Messages in this thread | | | Date | Thu, 6 Jan 2005 17:58:27 +0100 | From | Petr Vandrovec <> | Subject | Re: [PATCH] macros to detect existance of unlocked_ioctl and ioctl_compat |
| |
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@vc.cvut.cz - 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/
| |