In this case, all I want is to atomically access chip and board registers,
on the other side of the bus. Nothing to do with the bridge. A simple
spinlock would do.
Alberto.
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Friday, October 18, 2002 3: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
complain.
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…
Max
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
Another interesting thought is to have BIOS, no, no, not that, I mean EFI
(Extended Firmware Interface) to abstract southbridge and anything downward,
so that OS does not need a HAL. OS then abstract EFI for drivers and other
kernel modules. In that way, OS has an complete control over what driver can
access or not or what sychronization is required. Linux might be a cleaner
OS than it is today.
I may have shot my own foot for this statement.
Bi
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
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
complain.
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…
Max
You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%
Unless the BIOS or EFI or whatever is written with locking and SMP in
mind – and the learned folk here seem to say it is not, for the most
part – slapping a front-end to BIOS/EFI is probably going to be just a
Band-Aid, and a pretty crude one at that. For example, one might enforce
serialization, but if the underlying code wasn’t written with
serialization in mind, the serialization is likely to be not very
granular. More generally, it is not easy to apply serialization after
the fact.
And supposing one nevertheless does want to write such a front end, why
imagine that that is going to be different in scope from a HAL?
–
If replying by e-mail, please remove “nospam.” from the address.
James Antognini