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

[Arnd Bergmann]

On Dunnersdag 06 Januar 2005 18:53, Andi Kleen wrote:

> > * USB.  usbfs API is written in a way which does not allow you to safely wrap
> > it in "generic" 32->64 layer, and attempts to do it in non-generic way in usbfs
> > code itself did not look feasible year ago.  Even on current 64bit kernels it is not
> > possible to issue raw USB operations from 32bit apps, and I do not believe that
> > it is going to change - after all, just issuing ioctl through 64bit path from application
> > which is aware of 64bit kernel is quite simple, much simpler than any attempt to
> > make kernel dual-interface.
> 
> Agree that's a problem. We just need an alternative interface here
> or I try to come up with an x86-64 specific hack (I think it's possible
> to do the compatibility x86-64 specific, just not in compat code for
> all architectures who have truly separated user/kernel address spaces) 
> 
> I hope the USB people will eventually add a better interface here.
> Greg?

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.

	Arnd <><

Attachment: pgp00000.pgp
Description: signature