Re: question about ruby's keyboard.c & keybdev.c

[Benjamin H. <be...@ke...>]

>With the new code the keyboard just sends a "EV_SND, SND_BELL" event to
>beep. If the keyboard can do it, it will. Otherwise a separate "beep
>device" has to be registered that'll do the beep.
>
>This "beep device" will have a very simple driver that'll program the
>i8253 PIT on the PC, but can do other stuff elsewhere.

Sounds good...

>> (which have a SuperIO) but not on others, and I'd like to avoid turning
>> on (or asking about) CONFIG_ISA on machines which have a SuperIO but no
>> ISA slots.
>
>Ok. Let's then say that CONFIG_ISA is only for ISA *slots* and then we
>won't require it for hardware only found on mainboards (superio, etc).

The whole point of detecting ISA-like (superio or whatever else) devices
has been discussed a bit at OLS & kernel summit. One idea that popped up
would be to have:

 - Arch fills the device tree whith informations about known
    ISA-like devices in the system
 - Drivers for those rely on the device-tree and stop mucking
    around possibly non-existent HW
 - In order to deal with the problem of legacy stuff for which
   we don't know really if the device is here before "probing" for
   it at various known ports & IRQs, the solution is to have the arch
   put that info in the device-tree as well (some kind of "need probe"
   flag instead of a resource).

That way, existing legacy x86 would just populate the device-tree with
default entries for legacy serial, kbd, ... stuffs with a "need probe"
flag. Newer x86 could use whatever (ACPI ?) tables are passed by the
BIOS to populate the device-tree.
Non-x86 can do the right thing ;)

Ben.