Date: Fri, 7 Jan 2005 13:30:43 +0100
From: Andi Kleen <ak@suse.de>
To: Arnd Bergmann <arnd@arndb.de>
Cc: discuss@x86-64.org, Andi Kleen <ak@suse.de>,
       Petr Vandrovec <vandrove@vc.cvut.cz>,
       "Michael S. Tsirkin" <mst@mellanox.co.il>,
       Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org,
       greg@kroah.com
Subject: Re: [discuss] Re: [PATCH] macros to detect existance of unlocked_ioctl and ioctl_compat
Message-ID: <20050107123043.GB30264@wotan.suse.de>
References: <20041217014345.GA11926@mellanox.co.il> <20050106172613.GI5772@vana.vc.cvut.cz> <20050106175342.GA28889@wotan.suse.de> <200501071249.20767.arnd@arndb.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200501071249.20767.arnd@arndb.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1034
Lines: 20

> As a quick fix, wouldn't it be easy enough to just mark USBDEVFS_IOCTL as
> COMPATIBLE_IOCTL()? The number is actually different for 32 and 64 bit kernels,
> so a 32 bit application that knows about this could use 64 bit data structures
> and then just call ioctl(fd, USBDEVFS_IOCTL64, data) instead of using a weird
> hack to achieve exactly the same.
> Applications trying to call the 32 bit USBDEVFS_IOCTL would still see -EINVAL
> because there is no wrapper for this.
> Maybe the same can be done for some of the other ioctl calls. It effectively
> means moving part of the compat layer to user space from fs/compat_ioctl.c,
> but it appears that applications are already doing this.

That's too ugly. We would end up with different ABIs. 
I don't really want to do that, no.

-Andi
-
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/