On 17 October 2010 02:27, Kostik Belousov <kostik...@gmail.com> wrote: > On Sat, Oct 16, 2010 at 01:30:31PM +0200, Hans Petter Selasky wrote: >> On Saturday 16 October 2010 12:12:43 Hans Petter Selasky wrote: >> > On Saturday 16 October 2010 12:00:51 Kostik Belousov wrote: >> > > > USB has some shared memory structures which are used in both user-land >> > > > and kernel, which are not part of IOCTLs. Your approach means that >> > > > there are two sets of IOCTL's of all kinds, one for 32-bit and one for >> > > > 64-bit? >> > > >> > > For all kinds of structures that are not ABI-invariant, yes. >> > >> >> Hi, >> >> I've committed a patch to fix the buildworld breakage after feedback from >> Andreas Tobler. >> >> http://svn.freebsd.org/changeset/base/213920 >> >> > The approach that was discussed by me and Andrew earlier this year, was to >> > use uint64_t instead of "void *" in shared memory structures. The only >> > disadvantage is that this will force you to recompile libusb when you >> > update the kernel, and so we kind of put that approach aside to keep >> > seamless upgrade compatibility. >> >> This will also break the ABI on 8-stable and that was the main reason for >> going the other route. However, most applications access USB via libusb, so >> the breakage would probably be minimal. Do you have any opinions here? Should >> we make an exception for the general rule to not change the ABI within a >> stable branch? >> >> I'm attaching the other approach, which allows both 32 and 64 bit >> applications >> to use USB using the same IOCTL's. >> >> See thread: [FreeBSD 8/9] [64-bit IOCTL] Using the USB stack from a 32-bit >> application under a 64-bit kernel. >> > This is a choice of the poison :). > > Ideally, you would switch to the new ABI and keep old ABI shims around > for binary compatibility. In essence, this is equivalent to the proper > 32bit compat shims.
Is this change something that could be merged to 8.2? libusb consumers should not be affected but I do not know if any other applications would be affected. Andrew _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
