Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

RE: PCI Config spinlock handle - BIOS abstraction

Jake_OshinsJake_Oshins Member Posts: 1,058
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.

Jake Oshins
Windows Kernel Group

This posting is provided "AS IS" with no warranties, and confers no

-----Original Message-----
Subject: RE: PCI Config spinlock handle
From: Bi Chen <>
Date: Fri, 18 Oct 2002 15:29:03 -0700
X-Message-Number: 84

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.


-----Original Message-----
From: Maxim S. Shatskih []
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
should have
>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
access... hmmm...



  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    >got put to the test, as Apple bought NeXT right as I finished it and
    >everybody working on NT for PowerPC quit bothering.)

    Do you mean that the market niche for NT on Apple disappeared at this
    moment? And why? Was it because this was the sign that Apple wants to
    switch to serious multitasking kernel (purchased from NeXT) instead of
    puny multitasking of System %d?

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA