Date: Thu, 21 Jan 2010 08:58:51 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: "Wojciech A. Koszek" <wkoszek@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, emulation@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r202598 - head/sys/compat/linux Message-ID: <20100121085851.67964fn6pkgeauww@webmail.leidinger.net> In-Reply-To: <20100121015554.GI1990@FreeBSD.org> References: <201001182246.o0IMk6dw000346@svn.freebsd.org> <20100119091500.17856jhlpl7mjsow@webmail.leidinger.net> <20100121015554.GI1990@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting "Wojciech A. Koszek" <wkoszek@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@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? 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. Bye, Alexander. -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100121085851.67964fn6pkgeauww>