Petition against kernel configuration options madness...

Hi,

It took me about an hour to find out why my keyboard didn't work in 2.5.45. Well... after all it seemed that I need to enable 4 ! options inside the input configuration, just to get my default, nothing special PS/2 keyboard up and running. Oh, and I didn't even have my not so fancy boring default PS/2 mouse configured then. Guys, being able to configure everything is nice, but with the 2.5 kernel, things are definitely getting out of control IMHO.

Jos

don't blame your inability to understand the consequences of copying a .config across ~50 kernel releases on others thank you.

tomas szepe <[email protected]>

I wont, as long as you don blame someone who -to prevent buggy config files- downloaded a fresh 2.5.45 kernel, patched it with the bk-1 update and ran make menuconfig after that, of copying .config files.

Jos

This is potentially becoming a FAQ... I ran into this too, as did several people in the office. People who compile custom kernels seem to run into this when they first jump into 2.5.x. AT Keyboard support is definitely buried :/

Unfortunately I don't have any concrete suggestions for Vojtech (input subsystem maintainer), just a request that it becomes easier and more obvious how to configure the keyboard and mouse that is found on > 90% of all Linux users computers [IMO]...

Jeff

Too bad you don't have any suggestions. I completely agree this should be simplified, while I wouldn't be happy to lose the possibility of not compiling AT keyboard support in.

Vojtech Pavlik
SuSE Labs

Dear diary, on Sun, Nov 03, 2002 at 08:07:05PM CET, I got a letter, where Vojtech Pavlik <[email protected]> told me, that...

Well, why can't it be enabled by default? Other options are as well, and it's IMHO sane to enable keyboard and mice support by default. It should clear up the initial confusion as well.

I think that these options should be enabled by default:

[Userland interfaces]
Mouse interface
Legacy /dev/psaux (?)
(I suggest to make this non-default in 2.7, but maybe
we want shorter transition period?)

[Input I/O drivers]
Serial i/o support
i8042
Serial port line discipline

[Input device drivers]
Keyboards
AT keyboard support
Mice
Serial mouse (?)
(..or maybe not, this is really not so common as PS/2
lately)
PS/2 mouse

I think that those are absolute minimum and if anyone will want to have any of these explicitly off, he's more likely to know where to turn it off, rather than vice versa.

				Petr "Pasky" Baudis
.
This host is a black hole at HTTP wavelengths. GETs go in, and nothing
comes out, not even Hawking radiation.
                -- Graaagh the Mighty on rec.games.roguelike.angband
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/

All the needed options ARE enabled by default. (check arch/i386/defconfig)

Vojtech Pavlik
SuSE Labs

Now all you need is the users to know "make defconfig". I compile kernels since 1.2.13, but I didn't know the option till today. Sure, my fault, but I'm sure I'm not the only one.

Detail: IMHO the USB keyboard and mouse support should be on, and DRI should be enabled for all video cards, but that is a minor issue...

Jos

On Sun, 3 Nov 2002, Jos Hulzink wrote:

| On Sunday 03 November 2002 21:13, Vojtech Pavlik wrote:
| >
| > All the needed options ARE enabled by default. (check arch/i386/defconfig)
|
| Now all you need is the users to know "make defconfig". I compile kernels since 1.2.13, but I didn't know the option till today. Sure, my fault, but I'm sure I'm not the only one.
|
| Detail: IMHO the USB keyboard and mouse support should be on, and DRI should be enabled for all video cards, but that is a minor issue...

so while some people are attempting to "fix" this with defconfig or mostlikelyconfig, I'd like to remind people of the post-halloween doc from Dave Jones. He addresses this stuff in there. Does it possibly need even more emphasis there? and stronger hints for people to at least browse it before using 2.5.x for the first time?

~Randy

Dear diary, on Sun, Nov 03, 2002 at 09:13:08PM CET, I got a letter, where Vojtech Pavlik <[email protected]> told me, that...

Yes, but if this will be in the Kconfig as well (I mean adding "default y" lines, I can make a patch, if there's a desire), it will be offered as default even when doing make oldconfig, which is what most of the people is going to do (not make defconfig, most of people doesn't even know it exists and the rest probably wants to configure 2.5 based on their 2.4 configuration anyway).

				Petr "Pasky" Baudis
.
This host is a black hole at HTTP wavelengths. GETs go in, and nothing
comes out, not even Hawking radiation.
                -- Graaagh the Mighty on rec.games.roguelike.angband
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/

Hello,

this patch (against 2.5.45) introduces sane defaults for the input layer
configuration. The most common options default to yes now, so that with simply accepting defaults provided by make oldconfig, the 2.4 configuration can be converted to 2.5 configuration while preserving the basic keyboard, mouse and serial port support. This should prevent most users confusion when configuring their first 2.5 kernel. Please apply.

 drivers/input/Kconfig          |    2 ++
 drivers/input/keyboard/Kconfig |    2 ++
 drivers/input/mouse/Kconfig    |    2 ++
 drivers/input/serio/Kconfig    |    3 +++
 4 files changed, 9 insertions(+)

Kind regards,
Petr Baudis

diff -ru linux/drivers/input/Kconfig linux+pasky/drivers/input/Kconfig
@@ -28,6 +28,7 @@
 
 config INPUT_MOUSEDEV
 	tristate "Mouse interface"
+	default y
 	depends on INPUT
 	---help---
 	  Say Y here if you want your mouse to be accessible as char devices

@@ -45,6 +46,7 @@
 
 config INPUT_MOUSEDEV_PSAUX
 	bool "Provide legacy /dev/psaux device"
+	default y
 	depends on INPUT_MOUSEDEV
 
 config INPUT_MOUSEDEV_SCREEN_X

diff -ru linux/drivers/input/keyboard/Kconfig linux+pasky/drivers/input/keyboard/Kconfig
@@ -3,6 +3,7 @@
 #
 config INPUT_KEYBOARD
 	bool "Keyboards"
+	default y
 	depends on INPUT
 	help
 	  Say Y here, and a list of supported keyboards will be displayed.

@@ -12,6 +13,7 @@
 
 config KEYBOARD_ATKBD
 	tristate "AT keyboard support"
+	default y
 	depends on INPUT && INPUT_KEYBOARD && SERIO
 	---help---
 	  Say Y here if you want to use the standard AT keyboard. Usually

diff -ru linux/drivers/input/mouse/Kconfig linux+pasky/drivers/input/mouse/Kconfig
@@ -3,6 +3,7 @@
 #
 config INPUT_MOUSE
 	bool "Mice"
+	default y
 	depends on INPUT
 	help
 	  Say Y here, and a list of supported mice will be displayed.

@@ -12,6 +13,7 @@
 
 config MOUSE_PS2
 	tristate "PS/2 mouse"
+	default y
 	depends on INPUT && INPUT_MOUSE && SERIO
 	---help---
 	  Say Y here if you have a PS/2 mouse connected to your system. This

diff -ru linux/drivers/input/serio/Kconfig linux+pasky/drivers/input/serio/Kconfig
@@ -3,6 +3,7 @@
 #
 config SERIO
 	tristate "Serial i/o support"
+	default y
 	---help---
 	  Say Yes here if you have any input device that uses serial I/O to
 	  communicate with the system. This includes the 

@@ -19,6 +20,7 @@
 
 config SERIO_I8042
 	tristate "i8042 PC Keyboard controller"
+	default y
 	depends on SERIO
 	---help---
 	  i8042 is the chip over which the standard AT keyboard and PS/2

@@ -34,6 +36,7 @@
 
 config SERIO_SERPORT
 	tristate "Serial port line discipline"
+	default y
 	depends on SERIO
 	---help---
 	  Say Y here if you plan to use an input device (mouse, joystick,

Keep in mind that All the World's Not a PC. No doubt those options are enabled on the majority of kernels, by number, but linux supports many, many types of systems, and I'll bet on fair number of them, it doesn't make much sense to enable psaux mouse support!

So ... instead of saying default y' for these options, how about saying default IM_ON_A_PC' where IM_ON_A_PC is defined somehow. How, I don't know; it could be a separate config question in a very obvious place, perhaps itself having `default X86'.

Perhaps this should really be two flags, one IM_ON_A_PC meaning typical i386 pc with legacy devices', and the other, more general, being something like IM_ON_A_WORKSTATION. Then wierd things like psaux would say default IM_ON_A_PC', but more general things like keyboards would say `default IM_ON_A_WORKSTATION'.

[Yeah, those names are sucky, I know...]

Thanks,

-Miles

[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that 
            will  make every christian in the world foamm at the mouth? 
[iddt]      nurg, that's the goal 

How about a PC subarch and turning them on by default for it?

Bill

Something I have been thinking about for a while is a quick-config option (that sets some defaults that hold for 90% of the systems), or an expert mode that shows extra options. Though I understand that this is hard to do, and much hardware differs, I think it can be done for some basics like keyboard, mouse, USB and stuff.

Yes, this will cause your kernel to be bigger than optimal, for some drivers will be compiled in that are not used on your system. But if you want you can optimize things away after clicking <set defaults for standard IBM PC>.

If this idea is not blown away immediately, I'm willing to work this idea out a little, though I can understand that people call me an idiot...

Jos

I like this idea!

How about running the "quick config", which I can then use a base to customize?

Not at all!

-Nick

What about:

<*> serial i/o (mouse, keyboard...) support"
<*> PC PS/2 and keyboard controller (i8042)
<*> PS/2 mouse support
<*> Typical (AT) keyboard support
<*> Serial port (COM) <something> support
<*> Serial port (COM) mouse support
[*] Advanced keyboard support
<*> Other keyboards here
<*> [the other Things]

Yes, it confuses people who only wants a mouse working. Still i think it's better than selecting the driver controller and after that selecting the device controller (if i'm understanding the current menu ;) BTW, we'll never be able to put a <*> Mouse support so i think that this is the best way.

Also, the current menu has some things that i dislike ;)

- Please, don't use names such "i8042 ". Most of the people (even people in this list i guess) didn't know what a i8042 controller is until they had to configure that ;) "Help" is the right place for explainig that i guess ;)

- Replace "mice" by "mouse support" or something. English isn't the only language in the earth. Many people think that the plural of "mouse" is "mouses" ;)

- In the current menu, you can disable the i8042 thing and you still can see the [*] Keyboard entry alone.

and another (crap) suggestion could be to put the pc speaker support under a /proc/something and remove the menu entry ;)

Why not set the default option for AT Keyboard support on i386 platforms to "Y"?

Cheers,
Nicholas

Last month or so I suggested adding a hint for Appletalk, and I see that it is there now:

config LLC
tristate "ANSI/IEEE 802.2 Data link layer protocol (IPX, Appletalk)"

Such parenthetical remarks will no doubt help a little. You might try

@@ -5,7 +5,7 @@
 menu "Input device support"
 
 config INPUT
-       tristate
+       tristate "Input devices (needed for mouse, keyboard, ...)"
        default y
        ---help---
          Say Y here if you have any input device (mouse, keyboard, tablet,

and

@@ -2,7 +2,7 @@
 # Input core configuration
 #
 config SERIO
-       tristate "Serial i/o support"
+       tristate "Serial i/o support (needed for keyboard and mouse)"
        ---help---
          Say Yes here if you have any input device that uses serial I/O to
          communicate with the system. This includes the 

(and maybe also sth under keyboard, to tell people that what they have is called an AT keyboard).

Andries

Documentation isn't enough. It _has_ to be made simpler.
Its obvious that this is the #1 stumbling block to a 2.5 virgin right now. I fell over it myself when I merged it, as did Linus I believe. It's just not obvious enough.

Having it documented obviously isn't enough too. I covered this in the document[*] I wrote last week, which got ~3000 direct hits, ~7000 or so on Linux-today, and god knows how many elsewhere. (Either that, or my description of the problem sucked).

Dave

[*] http://www.codemonkey.org.uk/post-halloween-2.5.txt

| Dave Jones.        http://www.codemonkey.org.uk

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is a general merging issue. I personally didn't get affected (because USB only is good), but it was a big problem for 2.4.19-pre10, when HID input support became optional (so you can have HID for an embedded USB UPS server, without getting bloat).

The idea of using a kernel revisioning system is good, but things change between any two kernels (2.4.19-pre9 and 2.4.19-pre10 in this case).

Suggest that the kernel .config should be revisioned, and if the version doesn't match, make $BUILDTARGET (eg bzImage, vmlinux, modules, whatever) should not run. make install and make modules_install shouldn't run either.

Instead, if the version differences are minor (definition TBA), then make [|x|menu|old|m]config should copy the old .config to an alternative name (eg. .config-previous) and then for each option, we should pull from .config-previous, then def-config (if no entry in .config-previous), which we'd then have as a default. and allow the user to override.

Also note that this will NOT solve the problem described. When you move functionality into an existing section, which is turned off, you have to check every option. Consider the impact of creating a "make kernel boot" option three levels down in the AX.25 code. 99% of kernel builders wouidn't see it. Generally you only get this level of breakage in unstable series, so people need to rebuild their config from scratch anyway. Also, the intent of some options changes (consider those that no longer need any SCSI, because their IDE CD-RW device is now native)

Fundamentally, if you don't know how to build the configuration, this is a good time to learn, even if only by trial and error.

Brad

- --
http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9xaCaW6pHgIdAuOMRAiGlAJ9bHWOxXDameBdHyKhFQLfuImUmGgCgop2w NE66gEzpN4hNzPAoR4uMTcg=
=jxzW
-----END PGP SIGNATURE-----

Maybe we need some heuristics for "upgrading" old .config files in the event of a "make oldconfig". They could be of the form of rules like this:

CONFIG_obsolete1 && CONFIG_obsolete2 -> CONFIG_new1=y, CONFIG_new2=y

(In a separate file, and entries would be aged. Maybe config tools could even walk users through this interactively, or flag settings obtained this way specially, e.g. with a similing wizard icon ;-) Maybe even add some descriptive text after the rule.)

This still doesn't help for hard to find or obscurely named options, but at least people upgrading wouldn't be bitten every time something is renamed or restructured.

- Werner

  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         [email protected] /
/_http://www.almesberger.net/____________________________________________/

Hello All , The tools everyone has been discussing & thinking about out loud are nice items to have .

But has -anyone- thought of documenting the new structure & placing the url/referance into the 'README' ? Please ?

Tia , JimL
--

       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | [email protected] | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

Stop whining, 2.5 kernels are development kernels -> not *expected* to work %100!

Cheers,
Nicholas

But they are expected to be configured not so hardly

Correct me if I'm wrong, but we're here to work out the problems. That's one of the major meanings of "development", in my experience.

I was bitten too: I loaded my 2.4.19 configuration and looked through most options, but I overlooked this keyboard/mouse thing. I think it's not turned on by default if you load an existing configuration, which is probably not what we want.

Ciao,
    Flavio Stanchina
    Trento - Italy

Information is not knowledge. Knowledge is not wisdom.
Wisdom is not truth. Truth is not beauty. Beauty is not love.
Love is not music. Music is the best.
-- Frank Zappa

This is true, but if you are going to make a report, make a report, don't advocate changing something which works for most as it stands. From the subject, one got the idea that people wanted to do some willy-nilly rearranging of the configure options. The real issue here is that you really should *not* be copying 2.4 .config's over to a 2.5 tree. That way you'll be forced to go through all the options and get the proper "default" options for your platform enabled automatically.

Cheers,
Nicholas

I agree, the subject is misleading.

Why souldn't I be able to do that? I was hoping that options missing from the loaded config would be set to the default value, which in the case of standard AT keyboard and PS/2 mouse is "yes, of course I want that".

How long will it take to go through all the options, your old config file at hand, and check that everything you need is there? How easy would it be to make a mistake?

Ciao,
    Flavio Stanchina
    Trento - Italy

Information is not knowledge. Knowledge is not wisdom.
Wisdom is not truth. Truth is not beauty. Beauty is not love.
Love is not music. Music is the best.
-- Frank Zappa

So here goes the suggestion:

The config gets a version-Tag.

Changes before the second dot in the version print a warning that you should not copy configs between major-versions. (Maybe it is better to default to exit with the warning and an option to override the exit.)

Only configs without a version-Tag are tricky. Maybe there is a good(tm) config-option that can be used to guess if the config is from the current major-version (=2.5). All other configs are "old(tm)".

Bis denn

Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

This would only be helpful if you also had a description of what the user is expected to change. (And once you have this, you might as well automate the process a little more, as I've just described in another posting.)

Just telling the user that there might be problems isn't very helpful, in particular since most such version conflicts would be false alarms, e.g. name changes of some obscure controller I don't have anyway. I think most people are aware of the fact that "make oldconfig" may produce nonsense, but it's still annoying if it does.

Another easy extension to consider: after "make oldconfig", print the options that were found in .config, but which don't exist anymore. I've actually proposed this already two years ago, see also
http://marc.theaimsgroup.com/?l=linux-kernel&m=97298980521513&w=2

- Werner

  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         [email protected] /
/_http://www.almesberger.net/____________________________________________/