From: Jean Delvare <jdelvare@suse.de>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: Jiri Kosina <jkosina@suse.cz>, Michal Marek <mmarek@suse.cz>,
linux-input@vger.kernel.org,
linux-kbuild <linux-kbuild@vger.kernel.org>
Subject: Re: Dependencies in the HID subsystem
Date: Thu, 13 Jun 2013 08:58:29 +0200 [thread overview]
Message-ID: <1371106709.4289.7.camel@chaos.site> (raw)
In-Reply-To: <CANq1E4SPsF1SXC1Buh+VgK1MJ+LPKwQOqVk+xfA0oYqw7ptdqw@mail.gmail.com>
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
next prev parent reply other threads:[~2013-06-13 6:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-29 19:19 Dependencies in the HID subsystem Jean Delvare
2013-05-29 20:52 ` Jiri Kosina
2013-05-29 22:23 ` David Herrmann
2013-06-13 6:58 ` Jean Delvare [this message]
2013-06-13 7:11 ` Jean Delvare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1371106709.4289.7.camel@chaos.site \
--to=jdelvare@suse.de \
--cc=dh.herrmann@gmail.com \
--cc=jkosina@suse.cz \
--cc=linux-input@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=mmarek@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).