linux-kernel - Re: [PATCH 4/5] HID: autoload hid-multitouch as needed

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]

Message-ID: <20120308122303.GA11989@polaris.bitmath.org>
Date:	Thu, 8 Mar 2012 13:23:03 +0100
From:	"Henrik Rydberg" <rydberg@...omail.se>
To:	Stéphane Chatty <chatty@...c.fr>
Cc:	Jiri Kosina <jkosina@...e.cz>,
	"benjamin.tissoires" <benjamin.tissoires@...il.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/5] HID: autoload hid-multitouch as needed

On Thu, Mar 08, 2012 at 12:48:24PM +0100, Stéphane Chatty wrote:
> 
> Le 8 mars 2012 à 12:30, Henrik Rydberg a écrit :
> > 
> > The device-driver matching is done in the kernel, but driver (aka
> > module) loading is done from userland. The crux is to be able to tell
> > userland what driver to load for a certain device. In this case, it
> > means giving more information to userland via the device/modalias
> > construct. Or at least, that is the question. :-)
> > 
> 
> Oook, I understand. The current solution used by distros is to load
> the hid module statically, but then we don't want to do it for every
> new kind of device-specific module, right? Is this your point?

Yes, half of it. The other half is the observation that the problem of
device-driver assignment we face for hid devices seems to originate in
the definition of what a hid device is, i.e., the hid device
identifier. If the identifier was more detailed and one could
construct a new hid device dynamically from the reports, the problem
would go away. Consequentually, a more detailed identifier would solve
the module-loading problem as well. The major concern I have is if
this is feasible from a compatibility point of view.

> I had the feeling that the current hid code was somehow trying to be
> universal, thus making the point moot, and figured that we would
> need to reintegrate hid-multitouch into hid-core at some
> point. You're suggesting another, more distributed option, in which
> new categories of HID devices appear from time to time and are
> handled in new modules, right? Sounds interesting to me, I'd like to
> hear what the original designers of the hid module think of it.

Me too. Reading through the module code, it really seems to put
userland in charge, only providing sufficient information to be able
to load the right modules. If this was fully possible in hid, at least
one of the special blacklists would disappear. One would also be able
to split the current hid-input into several different drivers, for
instance, gaining some clarity in addition to memory savings.

Henrik
--
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/