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

From: Petr Vandrovec
Date: Thu Jan 06 2005 - 11:36:58 EST


On Thu, Jan 06, 2005 at 02:53:56PM +0000, Christoph Hellwig wrote:
> On Thu, Jan 06, 2005 at 04:06:36PM +0200, Michael S. Tsirkin wrote:
> > > It should be, unless there's some problem. In maybe a week or so.
> >
> > To make life bearable for out-of kernel modules, the following patch
> > adds 2 macros so that existance of unlocked_ioctl and ioctl_compat
> > can be easily detected.
>
> That's not the way we're making additions. Get your code merged and
> there won't be any need to detect the feature.

When Greg made sysfs GPL only, I've asked whether it is possible to merge
vmmon/vmnet in (and changing its license, of course). Answer on LKML was
quite clear: no, you are not interested in having vmmon/vmnet in Linux
kernel as you do not believe that they are usable for anything else than VMware.

So please tell me what I can do to satisfy you? You do not want our modules
in kernel tree, and you do not want to allow us to detect kernel interface
easily. Of course we can use autoconf-like scripts we are using for
example to detect pml4/pgd vs. pgd/pud vs. pgd/pmd/pte vs. pmd/pte only,
but each time you can detect feature by looking at flags and not by trying
to build one source after another detection is simpler and more reliable.

BTW, vmmon will still require register_ioctl32_conversion as we are using
(abusing) it to be able to issue 64bit ioctls from 32bit application. I
assume that there is no supported way how to issue 64bit ioctls from 32bit
aplication anymore after you disallow system-wide translations to be registered
by modules.

Best regards,
Petr Vandrovec
-
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/