I used to believe in just that sort of approach. I worked at IBM on
three or four HALs for different RS/6000 workstations, writing one each
time IBM's RS/6K division came out with a new model. Then, IBM,
Motorola and Apple came out with the CHRP (Common Hardware Reference
Platform) spec, which abstracted lots of things through runtime
firmware, and I wrote one last HAL, one that I thought could run all
future PowerPC machines by calling into firmware. (This never really
got put to the test, as Apple bought NeXT right as I finished it and
everybody working on NT for PowerPC quit bothering.)
I thought that it had been a good idea, one which should be applied more
broadly. But then I came to Microsoft and started working with a
different business model, once which involved running a single set of
binaries on literally thousands of different platforms. And what I
discovered, particularly because I was working with ACPI, was that no
two firmware implementations are alike. We end up building a huge hack
table that represents the behavior that we have to use to deal with all
of the BIOSes we know about.
I know that all of you struggle with trying to make your drivers work on
Win95, Win98, Win98SE, WinME, WinNT 4.0, Win2K and WinXP. Imagine our
task in trying to make an OS behave predictably running on 5000
different BIOSes. Further imagine your drivers having to deal with the
cross-product of our OSes and those 5000 BIOSes. (Even though a BIOS is
far simpler than an OS, and thus they are more alike than different, the
sheer number of them mean that the differences can't be contained.)
I'm sure that this message will draw some flames. That's just the
nature of the situation. But the truth is that we can't rely too
heavily on firmware simply because we can't test our software
sufficiently if we do. Usually, we can test it on fifteen or twenty
different chipsets (maybe even a few more) before we ship a product.
But there isn't any reasonable chance that we'll be able to test it with
more than a few hundred BIOSes groups, even though several thousand
exist at any given moment.
If the code we write has to take a few tens of chipsets into account,
that's almost manageable. If it has to treat each individual model of
machine in the world separately, then we have no hope of being able to
bring a product to market.
Windows Kernel Group
This posting is provided "AS IS" with no warranties, and confers no
Subject: RE: PCI Config spinlock handle
From: Bi Chen <xxxxx@AppStream.com>
Date: Fri, 18 Oct 2002 15:29:03 -0700
Another interesting thought is to have BIOS, no, no, not that, I mean
(Extended Firmware Interface) to abstract southbridge and anything
so that OS does not need a HAL. OS then abstract EFI for drivers and
kernel modules. In that way, OS has an complete control over what driver
access or not or what sychronization is required. Linux might be a
OS than it is today.
I may have shot my own foot for this statement.
From: Maxim S. Shatskih [mailto:firstname.lastname@example.org]
Sent: Friday, October 18, 2002 12:24 PM
To: NT Developers Interest List
Subject: [ntdev] RE: PCI Config spinlock handle
>level driver, I should have access to the PCI bus hardware and I
>the OS provide me a mechanism to enforce mutual exclusion.
...and the OS provides this mutual exclusion by banning any PCI bridge
accesses. So, when the OS does what you require, you start to
You see - if the driver for a PCI card accesses the PCI bridges, then
huge compatibility issues arrive.
Maybe MS should implement the "register for bridge ownership"
functionality for one and only one driver, but uncontrolled bridge