lkml.org 
[lkml]   [2010]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2010-05-20 19:05    [W:0.298 / U:0.468 seconds]
©2003-2014 Jasper Spaans. Advertise on this site