From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johan Hedberg Subject: Re: uhid: broken interface: 32/64-bit compatibility Date: Fri, 15 Feb 2013 14:00:22 +0200 Message-ID: <20130215120022.GA23694@x220> References: <20130215112911.68A98E0085@blue.fi.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: David Herrmann Cc: "Kirill A. Shutemov" , linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jiri Kosina , RavindranathX Doddi , Greg Kroah-Hartman , Linus Torvalds , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Marcel Holtmann List-Id: linux-api@vger.kernel.org Hi David, On Fri, Feb 15, 2013, David Herrmann wrote: > On Fri, Feb 15, 2013 at 12:29 PM, Kirill A. Shutemov > wrote: > > Hi David and all, > > > > There's claim in uhid.h that the interface is "compatible even between > > architectures". But it obviously is not true: struct uhid_create_req > > contains pointer which breaks everything. > > > > The easy way to demonstrate the issue is compile uhid-example.c with -m32 > > and try to run it on 64 bit kernel. Creating of the device will fail. > > Indeed, we missed that. We should probably also notify the HIDP > developers as "struct hidp_connadd_req" suffers from the same > problems. (CC'ed) > > > I don't see an easy way to fix this. Few options: > > > > 1. Replace the pointer with u64. It will fix the issue, but it breaks ABI > > which is never a good idea. Not sure how many users interface already > > has. > > The only users I am aware of is an HID debugging tool and experimental > HoG Bluetooth support (bluez). Maybe Marcel or Johan can comment > whether this is already used by bluez-5? If it is, then we shouldn't > break ABI and go with #2+#3. Otherwise, I think changing to u64 should > be ok. > On the other hand, it would break any future build for older stable > kernels so not breaking ABI is probably the best idea. Any comments? I > can add a COMPAT fix and a comment to fix this in the next version of > UHID_CREATE. The HoG code in BlueZ 5 does indeed use this API and it's also not anymore behind any kind of experimental flag (i.e. it is an officially supported feature). Johan