From: Arador <grundig@teleline.es>
To: Pavel Machek <pavel@suse.cz>
Cc: hch@infradead.org, ak@muc.de, linux-kernel@vger.kernel.org,
akpm@digeo.com, vojtech@suse.cz
Subject: Re: [PATCH] Making keyboard/mouse drivers dependent on CONFIG_EMBEDDED
Date: Sun, 8 Jun 2003 02:43:13 +0200 [thread overview]
Message-ID: <20030608024313.0280ae8e.grundig@teleline.es> (raw)
In-Reply-To: <20030607204340.GC667@elf.ucw.cz>
On Sat, 7 Jun 2003 22:43:40 +0200
Pavel Machek <pavel@suse.cz> wrote:
> Its more like "make oldconfig" limitation, IIRC. If you have some old
> config, it ignores defconfig and suggests you N for new options. And
> yes people were hitting that.
Even if they're not using oldconfig, some people i know uses to put
it as module (they use to think in "put everything you can as module")
I suggest hidding this under "input device support":
<*> Input devices (needed for keyboard, mouse, ...)
<*> Serial i/o support (needed for keyboard and mouse)
<*> i8042 PC Keyboard controller
<*> Serial port line discipline
[*] Keyboards
<*> AT keyboard support
[*] Mice
<*> PS/2 mouse
<*> Serial mouse
and enable all of them by default
Then make a
[ ] Advanced Input Device Support
which will show those menues and it will let
people to disable those very common options.
I mean, IMHO users who want to disable
PS/2 and keyboard support are "advanced" users
which want to enable/disable "advanced" options.
Personally i think this scheme also sucks,
"input device support" should be changed; and bad names should be killed
(in the real world who knows what a "<*> i8042 PC Keyboard controller" means)
so people really knows that they won't be able to type anything if they disable it.
In fact, they're not warned anywhere that they won't get a console if they don't
enable it. And the fact that the help entries say nothing about it, and
that we're supposed to be disabling "input", not "output" support makes it harder
for people to understand when configuring their first 2.5 kernel.
I can't count how many people i've seen falling this on irc (personally it took
me 3 times to get the right options; unexperienced people could take forever).
If this isn't changed it will be the most reported ever (personally i'd consider
it a "must-fix" item ;) as it could have very negative effects when 2.6 is out =)
Just my thougs; Diego Calleja.
next prev parent reply other threads:[~2003-06-08 0:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-07 6:34 Andi Kleen
2003-06-07 6:45 ` Aaron Lehmann
2003-06-07 17:02 ` Roman Zippel
2003-06-07 6:49 ` YOSHIFUJI Hideaki / 吉藤英明
2003-06-07 18:40 ` Andi Kleen
2003-06-07 20:18 ` Ryan Anderson
2003-06-07 7:26 ` Christoph Hellwig
2003-06-07 20:43 ` Pavel Machek
2003-06-08 0:43 ` Arador [this message]
2003-06-07 9:59 ` Vojtech Pavlik
2003-06-07 18:44 ` Andi Kleen
2003-06-07 20:27 ` Vojtech Pavlik
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=20030608024313.0280ae8e.grundig@teleline.es \
--to=grundig@teleline.es \
--cc=ak@muc.de \
--cc=akpm@digeo.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@suse.cz \
--cc=vojtech@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
all inboxes | Powered by JetHome®