svn commit: r213852 - in head: lib/libusb sys/dev/usb
thompsa at FreeBSD.org
Mon Nov 29 20:53:12 UTC 2010
On 17 October 2010 02:27, Kostik Belousov <kostikbel at 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.
>> I've committed a patch to fix the buildworld breakage after feedback from
>> Andreas Tobler.
>> > 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.
More information about the svn-src-all