Fix dependancies on keybdev.o

Right now drivers/input/keybdev.o depends on drivers/char/keyboard.o for handle_scancode, keyboard_tasklet and kbd_ledfunc. However, compiling drivers/char/keyboard.o isn't quite straight forward, as we have:
ifndef CONFIG_SUN_KEYBOARD
obj-$(CONFIG_VT) += keyboard.o $(KEYMAP) $(KEYBD)
else
obj-$(CONFIG_PCI) += keyboard.o $(KEYMAP)
endif
in drivers/char/Makefile

To attempt to work around this, I've come up with the following patch for drivers/input/Config.in. Comments?

Quoted 10 lines · Tom Rini

Right now drivers/input/keybdev.o depends on drivers/char/keyboard.o for handle_scancode, keyboard_tasklet and kbd_ledfunc. However, compiling drivers/char/keyboard.o isn't quite straight forward, as we have:
ifndef CONFIG_SUN_KEYBOARD
obj-$(CONFIG_VT) += keyboard.o $(KEYMAP) $(KEYBD)
else
obj-$(CONFIG_PCI) += keyboard.o $(KEYMAP)
endif
in drivers/char/Makefile

Quoted 2 lines

To attempt to work around this, I've come up with the following patch for drivers/input/Config.in. Comments?

Here is a bit of arch/i386/config.in:
<extract>

# input before char - char/joystick depends on it. As does USB.
#
source drivers/input/Config.in
source drivers/char/Config.in
</extract>

So it will still crap out, because CONFIG_VT and CONFIG_SUN_KEYBOARD won't be set early enough.

Three possible options, none of them especially good:
1. Do various munging of config and make setup and try to cover this.

2. Move keyboard handling code to input subsystem

3. Do wholesale backport of input subsystem from 2.5

Quoted 1 line · Brad Hards

2. Move keyboard handling code to input subsystem

I think that will work out the best. How's the attached look? It moves drivers/input/Config.in inside of drivers/char/Config.in and then fixes arches which had both. (Lightly tested from xconfig[1] for all arches which got changed).

Quoted 1 line

3. Do wholesale backport of input subsystem from 2.5

Not really an option (and 2.5 has this problem anyhow) since it's so invasive, once it's done.

Quoted 7 lines · Tom Rini

Quoted 1 line · Brad Hards

2. Move keyboard handling code to input subsystem

I think that will work out the best. How's the attached look? It moves drivers/input/Config.in inside of drivers/char/Config.in and then fixes arches which had both. (Lightly tested from xconfig[1] for all arches which got changed).

I'm opposed to further junk going into drivers/char. It is already an incomprehensible mess of unrelated code.

Actually, I've got another idea, based on some stuff that I've been working on for the ACPI "its not just power management" issue.

If you need to set something in drivers/input (per your original patch) that depends on things that are set in drivers/char (or drivers/usb, anything that comes later), then split the Config.in into two sections. One section contains the normal Config.in user-selectable options, and a second drivers/input/Config-post.in, that is sourced in at the end of arch/foo/config.in and contains only automated Config.in dependancies (ie define_bool) but no user selectable options.

Does this make sense? If not, I'll try for a patch that shows it later this morning.

Quoted 9 lines · Brad Hards

Quoted 7 lines · Tom Rini

Quoted 1 line · Brad Hards

2. Move keyboard handling code to input subsystem

I think that will work out the best. How's the attached look? It moves drivers/input/Config.in inside of drivers/char/Config.in and then fixes arches which had both. (Lightly tested from xconfig[1] for all arches which got changed).

Quoted 2 lines

I'm opposed to further junk going into drivers/char. It is already an incomprehensible mess of unrelated code.

drivers/char/Config.in isn't too bad right now. If you skip over the horrific mess that is serial support, anyhow. Perhaps moving some of the arch-specific questions out to arch/$(ARCH)/config.in

Quoted 11 lines

Actually, I've got another idea, based on some stuff that I've been working on for the ACPI "its not just power management" issue.

If you need to set something in drivers/input (per your original patch) that depends on things that are set in drivers/char (or drivers/usb, anything that comes later), then split the Config.in into two sections. One section contains the normal Config.in user-selectable options, and a second drivers/input/Config-post.in, that is sourced in at the end of arch/foo/config.in and contains only automated Config.in dependancies (ie define_bool) but no user selectable options.

Quoted 2 lines

Does this make sense? If not, I'll try for a patch that shows it later this morning.

I don't think this makes sense for input however, unless we kill off drivers/input/Config.in (and for sh/m68k/sparc64 just paste the lines in) and merge it into drivers/char/Config.in (CONFIG_INPUT, CONFIG_INPUT_{KEYB,MOUSE,EV}DEV) and drivers/char/joystick/Config.in (CONFIG_INPUT_JOYSTICK). I wouldn't be opposed to doing that...

And for USB (CONFIG_INPUT'ed) joysticks we aren't any worse off, and perhaps we could even move those into a USB menu.

Quoted 13 lines · Tom Rini

Quoted 11 lines · Brad Hards

Quoted 7 lines · Tom Rini

Quoted 1 line · Brad Hards

2. Move keyboard handling code to input subsystem

I think that will work out the best. How's the attached look? It moves drivers/input/Config.in inside of drivers/char/Config.in and then fixes arches which had both. (Lightly tested from xconfig[1] for all arches which got changed).

I'm opposed to further junk going into drivers/char. It is already an incomprehensible mess of unrelated code.

Quoted 3 lines

drivers/char/Config.in isn't too bad right now. If you skip over the horrific mess that is serial support, anyhow. Perhaps moving some of the arch-specific questions out to arch/$(ARCH)/config.in

I meant from a user viewpoint. It is just a mish-mash of essentially unrelated questions. I'd prefer to see options moved into menus that describe them. Ideally about a screen length of options (for variable screen resolutions and xconfig vs menuconfig :-)

Quoted 14 lines

Quoted 13 lines

Actually, I've got another idea, based on some stuff that I've been working on for the ACPI "its not just power management" issue.

If you need to set something in drivers/input (per your original patch) that depends on things that are set in drivers/char (or drivers/usb, anything that comes later), then split the Config.in into two sections. One section contains the normal Config.in user-selectable options, and a second drivers/input/Config-post.in, that is sourced in at the end of arch/foo/config.in and contains only automated Config.in dependancies (ie define_bool) but no user selectable options.

Does this make sense? If not, I'll try for a patch that shows it later this morning.

Quoted 5 lines

I don't think this makes sense for input however, unless we kill off drivers/input/Config.in (and for sh/m68k/sparc64 just paste the lines in) and merge it into drivers/char/Config.in (CONFIG_INPUT, CONFIG_INPUT_{KEYB,MOUSE,EV}DEV) and drivers/char/joystick/Config.in (CONFIG_INPUT_JOYSTICK). I wouldn't be opposed to doing that...

I think that I've explained it poorly. I'll patch.

Quoted 2 lines

And for USB (CONFIG_INPUT'ed) joysticks we aren't any worse off, and perhaps we could even move those into a USB menu.

That is where most of the input stuff came from :-)

My main concern is that by 2.6, I don't want the current mess with Config options. I want something that is logical and makes sense to people. Right now, the only reliable way to get a build is to either check every menu (and submenu, and subsubmenu), or to take a previously working config for that machine, make oldconfig, and hope for the best.