linux-kernel - Re: [GIT] HID

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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.LNX.2.00.1005201834190.28092@pobox.suse.cz>
Date:	Thu, 20 May 2010 18:36:11 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Don Prince <dhprince-devel@...oo.co.uk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT] HID

On Thu, 20 May 2010, Linus Torvalds wrote:

> Oh, and I notice that I shouldn't blame Don - this kind of crap is 
> apparently de rigeur in the HID layer. I only noticed because this time it 
> was a clearly very specialized driver and I started wondering what that 
> odd name was.
> 
> Guys, I can understand it if it's some kind of big-name "exists 
> everywhere" thing. Doing it for big vendors like Logitech devices may make 
> sense. But don't do it for random specialized hardware. 

Well, this is basically because of your request you made 1.5 years ago.

Originally, all the quirks were sprinkled all over the generic code, 
making it unmaintainable mess. Then the quirks for paricular 
devices/device groups were separated into idividual drivers, which meant 
quite a few new config options.

When I sent you pull request with this back then, you responded with

==
As to the Kconfig options - do they really add so much space that you need 
to ask for the quirks? You didn't use to. Can you make the questions 
depend on EMBEDDED, or at least on the HID_COMPAT thing or whatever?
==

Since then, I am keeping it organized in a way that drivers, which are 
really simple, trivial and small workarounds (descriptor/parser fixes), 
are selected in 'EMBEDDED'-way automatically.

Other larger drivers, which actually implement something substantial and 
have non-trivial code size impact, are added as a normal config options.

As all this EMBEDDED handling as been initially introduced on your 
request, I am perfectly fine removing it if you don't like it anymore.

> At least ask the user "Do you want to support all the HID crap in the 
> universe" to allow people to say Yes/No once (instead of for every 
> single crazy device).

That's definitely also an option. Do you want me to redo it this way 
before you'll be pulling it?

-- 
Jiri Kosina
SUSE Labs, Novell Inc.
--
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/