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

Alexander Leidinger Alexander at
Fri Jan 22 11:44:56 UTC 2010

Quoting "Wojciech A. Koszek" <wkoszek at> (from Thu, 21 Jan  
2010 02:55:55 +0100):

> On Tue, Jan 19, 2010 at 09:15:00AM +0100, Alexander Leidinger wrote:
>> Quoting "Wojciech A. Koszek" <wkoszek at> (from Mon, 18 Jan 2010
>> 22:46:06 +0000 (UTC)):
>>> Author: wkoszek
>>> Date: Mon Jan 18 22:46:06 2010
>>> New Revision: 202598
>>> URL:
>>> 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?

Unfortunately I do not follow you completely...

My concern is that someone maybe want to implement an ioctl which  
falls in the same range. As long as the ioctl is not in a range of  
ioctls of a normal linux kernel, it is fine for me. If in doubt, add a  
kernel option to either enable or disable (I'm not sure what makes  
more sense) the FreeBSD-usb-forward-part.


Once a word has been allowed to escape, it cannot be recalled.
		-- Quintus Horatius Flaccus (Horace)    Alexander @ PGP ID = B0063FE7       netchild @  : PGP ID = 72077137

More information about the svn-src-all mailing list