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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.LFD.2.00.1005200948210.23538@i5.linux-foundation.org>
Date:	Thu, 20 May 2010 10:01:09 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jiri Kosina <jkosina@...e.cz>
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, Jiri Kosina wrote:
> 
> 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.

I _entirely_ agree with splitting up quirks. There's nothing wrong with 
that.

However, what is wrong is when those quirks then become
 (a) fairly big drivers (ie not just one-liner "this has an extra button" 
     kind of things)
 (b) are enabled for default
AND
 (c) are for devices that are so rare that almost nobody cares.

We do use that "enable automatically for non-embedded", but we use it for 
common stuff, and for stuff that we _historically_ used to support. Not 
for new random drivers.

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

Well, I look at something like "hid-ortec.c", and it has basically a few 
lines of code, much of it __init, and I say "ok, that makes sense to not 
even ask about".

So I can see your argument. That said, I've never even _heard_ of ortek. 
Maybe it's some common chip and I use it every day. But even for something 
that small, I'd wonder how common they really are.

So that kensington driver is a good example of something where I do think 
it makes sense to make it default. It's small, and kensington is a big 
name.

But when the driver is several hundred lines, and the text size is 
probably in the kilobytes (I didn't compile that new driver, but even the 
trivial ones are a few hundred bytes) _and_ the driver is for something 
I've never even heard about, then I really think it shouldn't be enabled 
without asking.

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