svn commit: r202598 - head/sys/compat/linux
Alexander at Leidinger.net
Fri Jan 22 11:44:56 UTC 2010
Quoting "Wojciech A. Koszek" <wkoszek at FreeBSD.org> (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 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
>>> 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
> 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
> #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)
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
More information about the svn-src-all