Colin Jensen wrote:
> You can't seriously suggest that the operating system should be able to
> the motherboard type automatically! While in
*your* application, you
> hard code the motherboard setups into Linux, this
is generally Not A
Not motherboard type. Motherboard chipset type.
Detect only the chipset type will not solve the problem. The
wireing from the chipset to the PCI Slots ist the interessting
> Marcus put it best: "IRQ assignment can't be done in the operating
> this is for a simple reason: operating systems
generally can't be
> a particular motherboard. And THERE IS NO WAY to
automatically detect a
> motherboard type. NONE. NADA. CAN'T GO THERE. The BIOS, since it is
be *glued* to
the motherboard, is a much more reasonable choice for hard
You CAN detect a motherboard type, by grepping strings out of the BIOS
ROM. But that is not the point here. The motherboard CHIPSET type is
easily detected, generally by a simple PCI vendor/device id match.
WRT IRQ assignment, Marcus is wrong. In a hotplug system, the OS _must_
do the assignment. Even Microsoft knows this. That is why most
modern BIOS ROMs come with interrupt routing tables, which give the OS a
[somewhat] standard method for
I think you should not do the assignment in the OS but you
can do a reconfiguration there. All are talking about Linux
but I like to use poor old DOS and WinNT 4 and other OS and
I don't linke to write a device driver for PCI configuration
for each OS.
I agree, that the OS can change the settings made by the BIOS.
I don't understand the problem. If you like you can clear all
PCI registers and set up them again in the OS, but there
should be done something for all OS that can't do the
configuration. And one other thing: When the Linux code is the
best in the world, why not put it into the BIOS?
This is also why newer motherboards include a Windows' "IRQ driver" or
similar -- so the --OS-- can talk to your motherboard.
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message