svn commit: r202598 - head/sys/compat/linux

[Wojciech A. Koszek]

On Tue, Jan 19, 2010 at 09:15:00AM +0100, Alexander Leidinger wrote:
> Quoting "Wojciech A. Koszek" <wkoszek at FreeBSD.org> (from Mon, 18 Jan 2010 
> 22:46:06 +0000 (UTC)):
> 
>> Author: wkoszek
>> Date: Mon Jan 18 22:46:06 2010
>> New Revision: 202598
>> URL: http://svn.freebsd.org/changeset/base/202598
>> 
>> Log:
>>   Let us to use our libusb(3) in Linuxolator.
>> 
>>   With this change, Linux binaries can work with our libusb(3) when
>>   it's compiled against our header files on GNU/Linux system -- this
>>   solves the problem with differences between /dev layouts.
>> 
>>   With ported libusb(3), I am able to use my USB JTAG cable with Linux
>>   binaries that support it.
> 
> The commit log is IMHO omitting the info if you checked (or not) that there 
> is no linux ioctl in this range. It would also be nice if the comment in 
> linux_ioctl.h tells to check that there is no clash with a linux ioctl when 
> the min/max is changed.

Sorry for delay.

I have tested it against ioctl() calls submitted by ported libusb(3).
Apparently, all ioctl() requests in my execution path didn't hit our emulator,
thus I was getting warnings about unsupported ioctl(). Thus, I reserved a range
for them. However, it looks like conflict exists with Linux *SND* stuff.

I believe the easiest solution would be based on picking "untypable" values for
commands:

	#define BSDEMUL_USB_REQUEST      _IOWR(3, 1, struct usb_ctl_request)


And putting them into linux_ioctl.h just like any other ioctl(). Simple mapping
would be provided for those calls to our native USB stack. grep(1) says 3 or 4
passed as a ioctl() should be fine, since none of those seem to be used in
Linux.  I could bring the same macros to ported libusb(3) easily, so that we'd
be using something that Linuxolator can finally understand in a unique way.

Does is sound like an acceptable solution?

-- 
Wojciech A. Koszek
wkoszek at FreeBSD.org
http://FreeBSD.czest.pl/~wkoszek/