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.LNX.2.00.1005201905320.28092@pobox.suse.cz>
Date:	Thu, 20 May 2010 19:13:06 +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:

> 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.

Well the borderline is still a little bit vague, but I see your point.

Having the things we used to support even before the quirk splitup 
compiled without asking, and separating the rest of the drivers into 
'really really really small and trivial, or common enough' and 'the rest' 
makes sense. 
And explicitly asking for 'the rest'.

This would basically mean removing the 'EMBEDDED' crap from a few drivers 
in Kconfig. Do you want me to fix that now and redo the pull request, or 
are you going to pull it anyway and I will rearrange that in 2nd merge 
round later?

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