Dependencies in the HID subsystem

Dependencies in the HID subsystem

[Jean Delvare]

Hi all,

I am worried and confused by some Kconfig dependencies in the HID
subsystem.

There are 11 HID device drivers which are defined in drivers/hid/Kconfig
with:

	tristate "..." if EXPERT
	default !EXPERT

Unless EXPERT is enabled (and that's not the default), these driver
entries are hidden and automatically selected. If CONFIG_HID=m, they are
selected as modules. If CONFIG_HID=y, they are built into the kernel. So
it is impossible to have CONFIG_HID=y and build these device drivers as
modules - as device drivers typically are.

I would like to understand the reasoning behind this complexity. What is
so special about these 11 drivers, that we can't just let the (kernel
configuring) user chose if he/she wants them and in what form?

Wouldn't "default !EXPERT" and a good old "If unsure, say Y" in the help
text be enough?

I would be fine with "tristate ... if EXPERT" if I still had the choice
between built-in or modular when both are possible. Is there any chance
to change the meaning of this construct to that?

Also I find it unpleasant that this construct completely hides the
option from the user, as if it did not exist, except if other options
depend on it. This is inconsistent and makes it difficult for the user
to know whether a specific kernel version includes a given driver or not
(one has to check .config afterward to know the answer.)

Put in short, I don't like the way things are today and would welcome
changes in this area.

Thanks,
-- 
Jean Delvare
Suse L3

Re: Dependencies in the HID subsystem

[Jiri Kosina]

On Wed, 29 May 2013, Jean Delvare wrote:

> I am worried and confused by some Kconfig dependencies in the HID
> subsystem.
> 
> There are 11 HID device drivers which are defined in drivers/hid/Kconfig
> with:
> 
> 	tristate "..." if EXPERT
> 	default !EXPERT
> 
> Unless EXPERT is enabled (and that's not the default), these driver
> entries are hidden and automatically selected. If CONFIG_HID=m, they are
> selected as modules. If CONFIG_HID=y, they are built into the kernel. So
> it is impossible to have CONFIG_HID=y and build these device drivers as
> modules - as device drivers typically are.
> 
> I would like to understand the reasoning behind this complexity. What is
> so special about these 11 drivers, that we can't just let the (kernel
> configuring) user chose if he/she wants them and in what form?

That's quite a old story with some history behind. Linus himself 
originally requested it, then much later asked the same question you did. 
See some background here:

	https://lkml.org/lkml/2010/5/20/227

The thing is, that things indeed have changed quite a bit since then. We 
are no longer in a situation that the generic driver would serve 99.99% of 
the world and the specific drivers would be just quirks.

> Wouldn't "default !EXPERT" and a good old "If unsure, say Y" in the help
> text be enough?

Normally, yes. This was all introduced back when separating out all the 
messy quirks from generic hid driver into sub-drivers for maintaing 
sort-of backwards compatibility and avoid confusion.

> Also I find it unpleasant that this construct completely hides the
> option from the user, as if it did not exist, except if other options
> depend on it. This is inconsistent and makes it difficult for the user
> to know whether a specific kernel version includes a given driver or not
> (one has to check .config afterward to know the answer.)

Yes. Again, purely historical reasons.

> Put in short, I don't like the way things are today and would welcome
> changes in this area.

As things have changed a lot since 2.6.28, we can try to put things more 
in line now for 3.11 or so.

-- 
Jiri Kosina
SUSE Labs

Re: Dependencies in the HID subsystem

[David Herrmann]

Hi

On Wed, May 29, 2013 at 10:52 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Wed, 29 May 2013, Jean Delvare wrote:
>
>> I am worried and confused by some Kconfig dependencies in the HID
>> subsystem.
>>
>> There are 11 HID device drivers which are defined in drivers/hid/Kconfig
>> with:
>>
>>       tristate "..." if EXPERT
>>       default !EXPERT
>>
>> Unless EXPERT is enabled (and that's not the default), these driver
>> entries are hidden and automatically selected. If CONFIG_HID=m, they are
>> selected as modules. If CONFIG_HID=y, they are built into the kernel. So
>> it is impossible to have CONFIG_HID=y and build these device drivers as
>> modules - as device drivers typically are.
>>
>> I would like to understand the reasoning behind this complexity. What is
>> so special about these 11 drivers, that we can't just let the (kernel
>> configuring) user chose if he/she wants them and in what form?

For several reason I recommend CONFIG_EXPERT for all users, anyway.
But apart from that, what's wrong with "default y" and dropping any
CONFIG_EXPERT dependency? We can still keep the "tristate '..' if
EXPERT".

The CONFIG_EXPERT descriptions says "this option allows certain base
kernel options and settings to be disabled or tweaked". This really
doesn't say anything about "disable any non-standard options if this
is selected". So why do we default to "n" if CONFIG_EXPERT is
selected? This always bothered me because I don't expect the config to
change if I select it.

Cheers
David

Re: Dependencies in the HID subsystem

[Jean Delvare]

Hi David,

Sorry for the late reply.

Le Thursday 30 May 2013 à 00:23 +0200, David Herrmann a écrit :
> Hi
> 
> On Wed, May 29, 2013 at 10:52 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> > On Wed, 29 May 2013, Jean Delvare wrote:
> >
> >> I am worried and confused by some Kconfig dependencies in the HID
> >> subsystem.
> >>
> >> There are 11 HID device drivers which are defined in drivers/hid/Kconfig
> >> with:
> >>
> >>       tristate "..." if EXPERT
> >>       default !EXPERT
> >>
> >> Unless EXPERT is enabled (and that's not the default), these driver
> >> entries are hidden and automatically selected. If CONFIG_HID=m, they are
> >> selected as modules. If CONFIG_HID=y, they are built into the kernel. So
> >> it is impossible to have CONFIG_HID=y and build these device drivers as
> >> modules - as device drivers typically are.
> >>
> >> I would like to understand the reasoning behind this complexity. What is
> >> so special about these 11 drivers, that we can't just let the (kernel
> >> configuring) user chose if he/she wants them and in what form?
> 
> For several reason I recommend CONFIG_EXPERT for all users, anyway.
> But apart from that, what's wrong with "default y" and dropping any
> CONFIG_EXPERT dependency? We can still keep the "tristate '..' if
> EXPERT".

There is a contradiction in your proposal. The tristate "..." if EXPERT
_is_ a CONFIG_EXPERT dependency, and that's exactly what I would like to
see go away. "default y" would be fine with me.

> The CONFIG_EXPERT descriptions says "this option allows certain base
> kernel options and settings to be disabled or tweaked". This really
> doesn't say anything about "disable any non-standard options if this
> is selected". So why do we default to "n" if CONFIG_EXPERT is
> selected? This always bothered me because I don't expect the config to
> change if I select it.

I agree that this kind of option-dependent default value can easily be
confusing. I suppose it was done that way for historical reasons, to
minimize the effect of changes while the HID subsystem was being
reworked. But I would like to see it go away now.

-- 
Jean Delvare
Suse L3

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dependencies in the HID subsystem

[Jean Delvare]

Hi Jiri,

Sorry for the late reply.

Le Wednesday 29 May 2013 à 22:52 +0200, Jiri Kosina a écrit :
> On Wed, 29 May 2013, Jean Delvare wrote:
> 
> > I am worried and confused by some Kconfig dependencies in the HID
> > subsystem.
> > 
> > There are 11 HID device drivers which are defined in drivers/hid/Kconfig
> > with:
> > 
> > 	tristate "..." if EXPERT
> > 	default !EXPERT
> > 
> > Unless EXPERT is enabled (and that's not the default), these driver
> > entries are hidden and automatically selected. If CONFIG_HID=m, they are
> > selected as modules. If CONFIG_HID=y, they are built into the kernel. So
> > it is impossible to have CONFIG_HID=y and build these device drivers as
> > modules - as device drivers typically are.
> > 
> > I would like to understand the reasoning behind this complexity. What is
> > so special about these 11 drivers, that we can't just let the (kernel
> > configuring) user chose if he/she wants them and in what form?
> 
> That's quite a old story with some history behind. Linus himself 
> originally requested it, then much later asked the same question you did. 
> See some background here:
> 
> 	https://lkml.org/lkml/2010/5/20/227

This explains it all, thank you.

>> (...)
> > Put in short, I don't like the way things are today and would welcome
> > changes in this area.
> 
> As things have changed a lot since 2.6.28, we can try to put things more 
> in line now for 3.11 or so.

This is great news. Will it just happen, or is some contribution
expected from me? That's not my area, but if you want me to write some
patches or test things, just ask and I'll do my best.

Thanks,
-- 
Jean Delvare
Suse L3

--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html