linux-kernel - Re: [PATCH] usb/hid: The HID Simple Driver Interface 0.4.1 (core)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 6 Dec 2006 16:00:12 +0100 (CET)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Marcel Holtmann <marcel@...tmann.org>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Li Yu <raise.sail@...il.com>,
	Greg Kroah Hartman <greg@...ah.com>,
	linux-usb-devel <linux-usb-devel@...ts.sourceforge.net>,
	LKML <linux-kernel@...r.kernel.org>,
	Vincent Legoll <vincentlegoll@...il.com>,
	"Zephaniah E. Hull" <warp@...allh.com>, liyu <liyu@...ss.com.cn>
Subject: Re: [PATCH] usb/hid: The HID Simple Driver Interface 0.4.1 (core)

On Wed, 6 Dec 2006, Marcel Holtmann wrote:

> > I still have the same objection - the "simple'" code will have to be
> > compiled into the driver instead of being a separate module and
> > eventyally will lead to a monster-size HID module. We have this issue
> > with psmouse to a degree but with HID the growth potential is much
> > bigger IMO.

I guess that this paragraph wasn't for me, but rather for the author of 
the HID Simple Driver proposal, am I right?

> > Jiri, I have not looked at your patches yet (I need to do that) but

Please do, when you will have time. Any comments are very welcome, before 
I start actually heading for the merge.

> The transport actually doesn't care on how you interpret or tweak the
> events. This is not its job. It is a simple plain stupid transport.
> Every additional driver that you put on top of the HID parser will look
> at the VID/PID and then decide which input event to send or what to do.
> So from my understanding the generic one should work just fine, but in
> case we need some special handling you can load an extra driver to
> handle this. And this could be done as HID driver. One driver could be
> the new hidraw driver to allow raw access to the HID reports.

Yes, the hidraw driver is one of the things that I am planning to develop 
on top of the generic HID layer, after the HID split gets merged. 

The current patches mainly take the contents of drivers/usb/input, and 
separate the code to transport-specific and the rest, which is then put 
into drivers/hid (of course some code changes are needed) and USB-specific 
HID code is then hooked into this new HID layer. 
I have tried to verify that hooking bluetooth, in the state in which it 
currently is (plus the patches which are not in mainline, also because of 
non-existence of common HID code), would stay relatively easy task, 
hopefully.

This split is quite painful, as there are many things happening in USB all 
the time, so the best way seem to be just to perform big split (with 
needed changes) at once, and then develop other things on top of it (like 
hidraw).

-- 
Jiri Kosina
SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/