What should Driver Developers use instead of HalGetBusData.? Is there an
example in the 2003 DDK? Something like the pcidump.sys driver example?
It depends on what you are trying to do. If you are a function or filter
driver for a pci device then you can use the pnp methods that replace
HalGetBusData, otherwise, if for some reason you are terminally curious
about some other devices PCI config space, then HalGetBusData is a
reasonable choice, although it won’t work, reportedly, on all platforms for
all devices.
I documented the PnP defined methods for function and filter drivers here:
http://www.hollistech.com/Resources/Misc%20articles/getbusdata.htm a long
time ago, and there is also a similar Microsoft KB article on
http://www.microsoft.com/whdc/default.mspx
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Jacklin
Sent: Monday, July 26, 2004 9:35 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Substitute for HalGetBusDataWhat should Driver Developers use instead of HalGetBusData.?
Is there an example in the 2003 DDK? Something like the
pcidump.sys driver example?
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com
It depends on what you are trying to do. If all your driver needs is access
to the PCI config space of the PCI device that your driver controls, then
you can follow the information in the following KB article:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q253232
If on the other hand your driver needs access to the PCI config space of
other PCI devices then you would have to write a bus filter driver to filter
the PCI bus driver. This is not a trivial task.
It seems that it was intended that a driver never touch the PCI
configuration space of a device which it did not control. This makes sense
from a security/stability standpoint (well not really because if you can
install a driver on a system all bets are off anyway) but it makes utilities
and such a bit harder to make.
–
Bill McKenzie
Software Engineer - Prism 802.11 Wireless Solutions
Conexant Systems, Inc.
“Greg Jacklin” wrote in message news:xxxxx@ntdev…
> What should Driver Developers use instead of HalGetBusData.? Is there an
> example in the 2003 DDK? Something like the pcidump.sys driver example?
>
>
The modern Windows has no documented ways of accessing the whole PCI config
space. The drivers are only allowed to access the config space of their device.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Greg Jacklin”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, July 27, 2004 5:35 AM
Subject: [ntdev] Substitute for HalGetBusData
> What should Driver Developers use instead of HalGetBusData.? Is there an
> example in the 2003 DDK? Something like the pcidump.sys driver example?
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
The problem of course is monitoring software, how do you keep an eye at PCI
space, how do you monitor changes ? If you can’t write software that
reliably accesses the whole PCI space, you’re pretty much dooming a lot of
low level debugging to hardware-only probing. And while I find it easy
enough to put a few read-only bits in a bridge chip, I’m not sure I accept
that forbidding reads to the PCI space enhances security that much. I
believe that the OS should expose a spinlock to synchronize access to PCI
bus space, and maybe lock whatever they will as read-only, but the last word
on what should be done in a machine must be the user’s, not the OS’s.
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Bill McKenzie
Sent: Monday, July 26, 2004 11:30 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Substitute for HalGetBusData
It depends on what you are trying to do. If all your driver needs is access
to the PCI config space of the PCI device that your driver controls, then
you can follow the information in the following KB article:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q253232
If on the other hand your driver needs access to the PCI config space of
other PCI devices then you would have to write a bus filter driver to filter
the PCI bus driver. This is not a trivial task.
It seems that it was intended that a driver never touch the PCI
configuration space of a device which it did not control. This makes sense
from a security/stability standpoint (well not really because if you can
install a driver on a system all bets are off anyway) but it makes utilities
and such a bit harder to make.
–
Bill McKenzie
Software Engineer - Prism 802.11 Wireless Solutions
Conexant Systems, Inc.
“Greg Jacklin” wrote in message news:xxxxx@ntdev…
> What should Driver Developers use instead of HalGetBusData.? Is there an
> example in the 2003 DDK? Something like the pcidump.sys driver example?
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
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.
> -----Original Message-----
From: Bill McKenzie [mailto:xxxxx@conexant.com]
other PCI devices then you would have to write a bus filter
driver to filter
the PCI bus driver. This is not a trivial task.
The question has been for many times, seems to me many people wants it. If
anyone sponsored some web space, I could probably post my filter driver
there-
Calvin
Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com
Calvin Guan wrote:
The question has been for many times, seems to me many people wants it.
If anyone sponsored some web space, I could probably post my filter
driver there-
Send it to us, dude. Assuming it’s clean, and it doesn’t do anything
horrible, we’ll stick it on OSR Online for download, with you marked
clearly as the contributor.
Peter
OSR
I could post it on my web page.
From: Calvin Guan
>Reply-To: “Windows System Software Devs Interest List”
>
>To: “Windows System Software Devs Interest List”
>Subject: RE: [ntdev] Substitute for HalGetBusData
>Date: Tue, 27 Jul 2004 13:58:13 -0400
>
> > -----Original Message-----
> > From: Bill McKenzie [mailto:xxxxx@conexant.com]
>
> > other PCI devices then you would have to write a bus filter
> > driver to filter
> > the PCI bus driver. This is not a trivial task.
>
>The question has been for many times, seems to me many people wants it. If
>anyone sponsored some web space, I could probably post my filter driver
>there-
>
>Calvin
>-
>Calvin Guan Software Engineer
>ATI Technologies Inc. www.ati.com
>
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
-------------------
Greg Jacklin
Email: xxxxx@hotmail.com
CELL: 503.504.7220
-------------------
I whole hardidly agree with Alberto.
People will probe the PCI config space
whether or not windows believes they
should or not. If they DO expose a formal
method for this then life would be
better for all ;-].
----- Original Message -----
From: “Moreira, Alberto”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, July 27, 2004 8:26 AM
Subject: RE: [ntdev] Substitute for HalGetBusData
> The problem of course is monitoring software, how do you keep an eye at
PCI
> space, how do you monitor changes ? If you can’t write software that
> reliably accesses the whole PCI space, you’re pretty much dooming a lot of
> low level debugging to hardware-only probing. And while I find it easy
> enough to put a few read-only bits in a bridge chip, I’m not sure I accept
> that forbidding reads to the PCI space enhances security that much. I
> believe that the OS should expose a spinlock to synchronize access to PCI
> bus space, and maybe lock whatever they will as read-only, but the last
word
> on what should be done in a machine must be the user’s, not the OS’s.
>
> Alberto.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Bill McKenzie
> Sent: Monday, July 26, 2004 11:30 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Substitute for HalGetBusData
>
>
> It depends on what you are trying to do. If all your driver needs is
access
> to the PCI config space of the PCI device that your driver controls, then
> you can follow the information in the following KB article:
>
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q253232
>
> If on the other hand your driver needs access to the PCI config space of
> other PCI devices then you would have to write a bus filter driver to
filter
> the PCI bus driver. This is not a trivial task.
>
> It seems that it was intended that a driver never touch the PCI
> configuration space of a device which it did not control. This makes
sense
> from a security/stability standpoint (well not really because if you can
> install a driver on a system all bets are off anyway) but it makes
utilities
> and such a bit harder to make.
>
> –
> Bill McKenzie
> Software Engineer - Prism 802.11 Wireless Solutions
> Conexant Systems, Inc.
>
>
> “Greg Jacklin” wrote in message news:xxxxx@ntdev…
> > What should Driver Developers use instead of HalGetBusData.? Is there
an
> > example in the 2003 DDK? Something like the pcidump.sys driver example?
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> 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.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hotmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Well I whole-hardidily disagree 
That a *debugging* tool might need to access pci config space for devices it
is not managing is indeed true. That in general random kernel or user mode
components need to or rather should access pci config space for devices that
they are not managing is a very dubious proposition.
If in fact you are managing PCI busses rather than a PCI device on a bus
then write a PCI bus filter driver. If you aren’t managing PCI busses, and
you are not a debugger, why exactly do you think it is appropriate for your
program to be probing PCI config space?
I’d prefer to keep the programs accessing MY PCI device limited to my
driver, the PCI bus manager, and filter drivers using defined interfaces in
my device stack.
=====================
Mark Roddy
-----Original Message-----
From: Greg Jacklin [mailto:xxxxx@hotmail.com]
Sent: Tuesday, July 27, 2004 4:35 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Substitute for HalGetBusData
I whole hardidly agree with Alberto.
People will probe the PCI config space
whether or not windows believes they
should or not. If they DO expose a formal method for this then life would
be better for all ;-].
----- Original Message -----
From: “Moreira, Alberto”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, July 27, 2004 8:26 AM
Subject: RE: [ntdev] Substitute for HalGetBusData
> The problem of course is monitoring software, how do you keep an eye at
PCI
> space, how do you monitor changes ? If you can’t write software that
> reliably accesses the whole PCI space, you’re pretty much dooming a lot of
> low level debugging to hardware-only probing. And while I find it easy
> enough to put a few read-only bits in a bridge chip, I’m not sure I accept
> that forbidding reads to the PCI space enhances security that much. I
> believe that the OS should expose a spinlock to synchronize access to PCI
> bus space, and maybe lock whatever they will as read-only, but the last
word
> on what should be done in a machine must be the user’s, not the OS’s.
>
> Alberto.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Bill McKenzie
> Sent: Monday, July 26, 2004 11:30 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Substitute for HalGetBusData
>
>
> It depends on what you are trying to do. If all your driver needs is
access
> to the PCI config space of the PCI device that your driver controls, then
> you can follow the information in the following KB article:
>
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q253232
>
> If on the other hand your driver needs access to the PCI config space of
> other PCI devices then you would have to write a bus filter driver to
filter
> the PCI bus driver. This is not a trivial task.
>
> It seems that it was intended that a driver never touch the PCI
> configuration space of a device which it did not control. This makes
sense
> from a security/stability standpoint (well not really because if you can
> install a driver on a system all bets are off anyway) but it makes
utilities
> and such a bit harder to make.
>
> –
> Bill McKenzie
> Software Engineer - Prism 802.11 Wireless Solutions
> Conexant Systems, Inc.
>
>
> “Greg Jacklin” wrote in message news:xxxxx@ntdev…
> > What should Driver Developers use instead of HalGetBusData.? Is there
an
> > example in the 2003 DDK? Something like the pcidump.sys driver example?
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> 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.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hotmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
First, it’s my machine: not Microsoft’s. Second, the OS must not “in
charge”: it must be a helper and a facilitator. Third, it’s nobody’s
business to tell me what I will or will not do with my own machine.
It’s a *personal* computer, remember ? Otherwise, should we go back to the
mainframe culture of the 60’s ? I hope not.
So, I may want to write a program to see for myself what exactly each PCI
board is hogging. I may want to write a sample PCI enumerator driver to
expose my students to a read-only multiprocessor-aware entry-level piece of
kernel code. I may want to find my graphics board’s video memory so that my
diagnostic program can prod it and see if my graphics chip is working. I may
want to write a program that keeps tabs of what the OS is doing to my
hardware behind my back. I may want to time bus level events.
For example, once I had a problem passing WHQL with one of my OpenGL
drivers. It just happened that even though the OpenGL standard did not
demand that level of accuracy, the WHQL test would fail me if a fogged pixel
ended up having a 1/255 intensity as oposed to a 2/255 intensity: that’s one
pixel, mind you, in a whole window. Or it would fail me if my Bresenham drew
one of my line pixels at 371,478 instead of 370,478. So, I needed to tag my
pixels in video memory through some independent means, for example,
pre-drawing the line and using some ROP to highlight discrepancies, or
reading the fogged pixel from video memory and comparing it to the value I
expected to see. This code would be added to my OpenGL driver code, on the
fly. Well, to do that, I needed to access video memory, raw: I must find
where it is, make sure it’s mapped into some virtual memory page, and so on.
Or another example, a chip I worked with had a very peculiar texture format,
for performance reasons. To write a texture loader was a nontrivial task,
and debugging it was tough. The thing to do was again to write pixels to
video memory, by hand, and see if what we loaded matched it by running a
byte-by-byte compare, or just read the loaded texture back into host memory
and compare it: again, access to the wire was necessary.
I could go on. Production is just the tail end of a long and hard driver
development process, and to me as a kernel dev what matters is the level of
support the OS gives to my development activities: I’m a kernel dev, not an
IT manager.
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: Wednesday, July 28, 2004 9:50 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Substitute for HalGetBusData
Well I whole-hardidily disagree
That a *debugging* tool might need to access pci config space for devices it
is not managing is indeed true. That in general random kernel or user mode
components need to or rather should access pci config space for devices that
they are not managing is a very dubious proposition.
If in fact you are managing PCI busses rather than a PCI device on a bus
then write a PCI bus filter driver. If you aren’t managing PCI busses, and
you are not a debugger, why exactly do you think it is appropriate for your
program to be probing PCI config space?
I’d prefer to keep the programs accessing MY PCI device limited to my
driver, the PCI bus manager, and filter drivers using defined interfaces in
my device stack.
=====================
Mark Roddy
-----Original Message-----
From: Greg Jacklin [mailto:xxxxx@hotmail.com]
Sent: Tuesday, July 27, 2004 4:35 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Substitute for HalGetBusData
I whole hardidly agree with Alberto.
People will probe the PCI config space
whether or not windows believes they
should or not. If they DO expose a formal method for this then life would
be better for all ;-].
----- Original Message -----
From: “Moreira, Alberto”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, July 27, 2004 8:26 AM
Subject: RE: [ntdev] Substitute for HalGetBusData
> The problem of course is monitoring software, how do you keep an eye at
PCI
> space, how do you monitor changes ? If you can’t write software that
> reliably accesses the whole PCI space, you’re pretty much dooming a lot of
> low level debugging to hardware-only probing. And while I find it easy
> enough to put a few read-only bits in a bridge chip, I’m not sure I accept
> that forbidding reads to the PCI space enhances security that much. I
> believe that the OS should expose a spinlock to synchronize access to PCI
> bus space, and maybe lock whatever they will as read-only, but the last
word
> on what should be done in a machine must be the user’s, not the OS’s.
>
> Alberto.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Bill McKenzie
> Sent: Monday, July 26, 2004 11:30 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Substitute for HalGetBusData
>
>
> It depends on what you are trying to do. If all your driver needs is
access
> to the PCI config space of the PCI device that your driver controls, then
> you can follow the information in the following KB article:
>
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q253232
>
> If on the other hand your driver needs access to the PCI config space of
> other PCI devices then you would have to write a bus filter driver to
filter
> the PCI bus driver. This is not a trivial task.
>
> It seems that it was intended that a driver never touch the PCI
> configuration space of a device which it did not control. This makes
sense
> from a security/stability standpoint (well not really because if you can
> install a driver on a system all bets are off anyway) but it makes
utilities
> and such a bit harder to make.
>
> –
> Bill McKenzie
> Software Engineer - Prism 802.11 Wireless Solutions
> Conexant Systems, Inc.
>
>
> “Greg Jacklin” wrote in message news:xxxxx@ntdev…
> > What should Driver Developers use instead of HalGetBusData.? Is there
an
> > example in the 2003 DDK? Something like the pcidump.sys driver example?
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> 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.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hotmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
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.
I absolutely agree alberto, it is your machine and you are free to do
anything you want with it. Equally, it is Microsoft’s operating system, that
they have to support, and they can do anything they want with their
operating system.
I suggest that you not use Windows as an operating system as it is
constantly getting in the way of you doing your own thing. Linux, with its
complete source access and consequent ability for you to redesign it as you
see fit, would be a far better choice for you.
For consumers out there who just want their systems to work, I think Windows
remains a better choice, although my mom will indeed not be able to view PCI
bus config space.
=====================
Mark Roddy
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Wednesday, July 28, 2004 10:46 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Substitute for HalGetBusData
First, it’s my machine: not Microsoft’s. Second, the OS must not “in
charge”: it must be a helper and a facilitator. Third, it’s nobody’s
business to tell me what I will or will not do with my own machine.
It’s a *personal* computer, remember ? Otherwise, should we go back to the
mainframe culture of the 60’s ? I hope not.
So, I may want to write a program to see for myself what exactly each PCI
board is hogging. I may want to write a sample PCI enumerator driver to
expose my students to a read-only multiprocessor-aware entry-level piece of
kernel code. I may want to find my graphics board’s video memory so that my
diagnostic program can prod it and see if my graphics chip is working. I may
want to write a program that keeps tabs of what the OS is doing to my
hardware behind my back. I may want to time bus level events.
For example, once I had a problem passing WHQL with one of my OpenGL
drivers. It just happened that even though the OpenGL standard did not
demand that level of accuracy, the WHQL test would fail me if a fogged pixel
ended up having a 1/255 intensity as oposed to a 2/255 intensity: that’s one
pixel, mind you, in a whole window. Or it would fail me if my Bresenham drew
one of my line pixels at 371,478 instead of 370,478. So, I needed to tag my
pixels in video memory through some independent means, for example,
pre-drawing the line and using some ROP to highlight discrepancies, or
reading the fogged pixel from video memory and comparing it to the value I
expected to see. This code would be added to my OpenGL driver code, on the
fly. Well, to do that, I needed to access video memory, raw: I must find
where it is, make sure it’s mapped into some virtual memory page, and so on.
Or another example, a chip I worked with had a very peculiar texture format,
for performance reasons. To write a texture loader was a nontrivial task,
and debugging it was tough. The thing to do was again to write pixels to
video memory, by hand, and see if what we loaded matched it by running a
byte-by-byte compare, or just read the loaded texture back into host memory
and compare it: again, access to the wire was necessary.
I could go on. Production is just the tail end of a long and hard driver
development process, and to me as a kernel dev what matters is the level of
support the OS gives to my development activities: I’m a kernel dev, not an
IT manager.
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: Wednesday, July 28, 2004 9:50 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Substitute for HalGetBusData
Well I whole-hardidily disagree
That a *debugging* tool might need to access pci config space for devices it
is not managing is indeed true. That in general random kernel or user mode
components need to or rather should access pci config space for devices that
they are not managing is a very dubious proposition.
If in fact you are managing PCI busses rather than a PCI device on a bus
then write a PCI bus filter driver. If you aren’t managing PCI busses, and
you are not a debugger, why exactly do you think it is appropriate for your
program to be probing PCI config space?
I’d prefer to keep the programs accessing MY PCI device limited to my
driver, the PCI bus manager, and filter drivers using defined interfaces in
my device stack.
=====================
Mark Roddy
-----Original Message-----
From: Greg Jacklin [mailto:xxxxx@hotmail.com]
Sent: Tuesday, July 27, 2004 4:35 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Substitute for HalGetBusData
I whole hardidly agree with Alberto.
People will probe the PCI config space
whether or not windows believes they
should or not. If they DO expose a formal method for this then life would
be better for all ;-].
----- Original Message -----
From: “Moreira, Alberto”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, July 27, 2004 8:26 AM
Subject: RE: [ntdev] Substitute for HalGetBusData
> The problem of course is monitoring software, how do you keep an eye
> at
PCI
> space, how do you monitor changes ? If you can’t write software that
> reliably accesses the whole PCI space, you’re pretty much dooming a
> lot of low level debugging to hardware-only probing. And while I find
> it easy enough to put a few read-only bits in a bridge chip, I’m not
> sure I accept that forbidding reads to the PCI space enhances security
> that much. I believe that the OS should expose a spinlock to
> synchronize access to PCI bus space, and maybe lock whatever they will
> as read-only, but the last
word
> on what should be done in a machine must be the user’s, not the OS’s.
>
> Alberto.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Bill McKenzie
> Sent: Monday, July 26, 2004 11:30 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Substitute for HalGetBusData
>
>
> It depends on what you are trying to do. If all your driver needs is
access
> to the PCI config space of the PCI device that your driver controls,
> then you can follow the information in the following KB article:
>
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q253232
>
> If on the other hand your driver needs access to the PCI config space
> of other PCI devices then you would have to write a bus filter driver
> to
filter
> the PCI bus driver. This is not a trivial task.
>
> It seems that it was intended that a driver never touch the PCI
> configuration space of a device which it did not control. This makes
sense
> from a security/stability standpoint (well not really because if you
> can install a driver on a system all bets are off anyway) but it makes
utilities
> and such a bit harder to make.
>
> –
> Bill McKenzie
> Software Engineer - Prism 802.11 Wireless Solutions Conexant Systems,
> Inc.
>
>
> “Greg Jacklin” wrote in message news:xxxxx@ntdev…
> > What should Driver Developers use instead of HalGetBusData.? Is
> > there
an
> > example in the 2003 DDK? Something like the pcidump.sys driver example?
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@compuware.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
>
> 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.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hotmail.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
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.
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
OooOOo. .oOOOo. oOoOOoOOo OOooOoO o o o .O o. o o O
O O O o o O o
o .O o O O oOooO o
OOooOO’ O o o O O
o o o O O o O
O O o O' O o o . O o OoooO’ o’ O’ OOoOooO
poor alberto …
Norbert.
I absolutely agree alberto, it is your machine and you are free to do
anything you want with it. Equally, it is Microsoft’s operating system, that
they have to support, and they can do anything they want with their
operating system.
I suggest that you not use Windows as an operating system as it is
constantly getting in the way of you doing your own thing. Linux, with its
complete source access and consequent ability for you to redesign it as you
see fit, would be a far better choice for you.
For consumers out there who just want their systems to work, I think Windows
remains a better choice, although my mom will indeed not be able to view PCI
bus config space.
=====================
Mark Roddy
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Wednesday, July 28, 2004 10:46 AM
To: Windows System Software Devs Interest List
Subject: RE: Substitute for HalGetBusData
First, it’s my machine: not Microsoft’s. Second, the OS must not “in
charge”: it must be a helper and a facilitator. Third, it’s nobody’s
business to tell me what I will or will not do with my own machine.
It’s a *personal* computer, remember ? Otherwise, should we go back to the
mainframe culture of the 60’s ? I hope not.
So, I may want to write a program to see for myself what exactly each PCI
board is hogging. I may want to write a sample PCI enumerator driver to
expose my students to a read-only multiprocessor-aware entry-level piece of
kernel code. I may want to find my graphics board’s video memory so that my
diagnostic program can prod it and see if my graphics chip is working. I may
want to write a program that keeps tabs of what the OS is doing to my
hardware behind my back. I may want to time bus level events.
For example, once I had a problem passing WHQL with one of my OpenGL
drivers. It just happened that even though the OpenGL standard did not
demand that level of accuracy, the WHQL test would fail me if a fogged pixel
ended up having a 1/255 intensity as oposed to a 2/255 intensity: that’s one
pixel, mind you, in a whole window. Or it would fail me if my Bresenham drew
one of my line pixels at 371,478 instead of 370,478. So, I needed to tag my
pixels in video memory through some independent means, for example,
pre-drawing the line and using some ROP to highlight discrepancies, or
reading the fogged pixel from video memory and comparing it to the value I
expected to see. This code would be added to my OpenGL driver code, on the
fly. Well, to do that, I needed to access video memory, raw: I must find
where it is, make sure it’s mapped into some virtual memory page, and so on.
Or another example, a chip I worked with had a very peculiar texture format,
for performance reasons. To write a texture loader was a nontrivial task,
and debugging it was tough. The thing to do was again to write pixels to
video memory, by hand, and see if what we loaded matched it by running a
byte-by-byte compare, or just read the loaded texture back into host memory
and compare it: again, access to the wire was necessary.
I could go on. Production is just the tail end of a long and hard driver
development process, and to me as a kernel dev what matters is the level of
support the OS gives to my development activities: I’m a kernel dev, not an
IT manager.
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: Wednesday, July 28, 2004 9:50 AM
To: Windows System Software Devs Interest List
Subject: RE: Substitute for HalGetBusData
Well I whole-hardidily disagree
That a *debugging* tool might need to access pci config space for devices it
is not managing is indeed true. That in general random kernel or user mode
components need to or rather should access pci config space for devices that
they are not managing is a very dubious proposition.
If in fact you are managing PCI busses rather than a PCI device on a bus
then write a PCI bus filter driver. If you aren’t managing PCI busses, and
you are not a debugger, why exactly do you think it is appropriate for your
program to be probing PCI config space?
I’d prefer to keep the programs accessing MY PCI device limited to my
driver, the PCI bus manager, and filter drivers using defined interfaces in
my device stack.
=====================
Mark Roddy
-----Original Message-----
From: Greg Jacklin [mailto:xxxxx@hotmail.com]
Sent: Tuesday, July 27, 2004 4:35 PM
To: Windows System Software Devs Interest List
Subject: Re: Substitute for HalGetBusData
I whole hardidly agree with Alberto.
People will probe the PCI config space
whether or not windows believes they
should or not. If they DO expose a formal method for this then life would
be better for all ;-].
----- Original Message -----
From: “Moreira, Alberto”
> To: “Windows System Software Devs Interest List”
> Sent: Tuesday, July 27, 2004 8:26 AM
> Subject: RE: Substitute for HalGetBusData
>> The problem of course is monitoring software, how do you keep an eye
>> at
> PCI
>> space, how do you monitor changes ? If you can’t write software that
>> reliably accesses the whole PCI space, you’re pretty much dooming a
>> lot of low level debugging to hardware-only probing. And while I find
>> it easy enough to put a few read-only bits in a bridge chip, I’m not
>> sure I accept that forbidding reads to the PCI space enhances security
>> that much. I believe that the OS should expose a spinlock to
>> synchronize access to PCI bus space, and maybe lock whatever they will
>> as read-only, but the last
> word
>> on what should be done in a machine must be the user’s, not the OS’s.
>>
>> Alberto.
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com]On Behalf Of Bill McKenzie
>> Sent: Monday, July 26, 2004 11:30 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] Substitute for HalGetBusData
>>
>>
>> It depends on what you are trying to do. If all your driver needs is
> access
>> to the PCI config space of the PCI device that your driver controls,
>> then you can follow the information in the following KB article:
>>
>> http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q253232
>>
>> If on the other hand your driver needs access to the PCI config space
>> of other PCI devices then you would have to write a bus filter driver
>> to
> filter
>> the PCI bus driver. This is not a trivial task.
>>
>> It seems that it was intended that a driver never touch the PCI
>> configuration space of a device which it did not control. This makes
> sense
>> from a security/stability standpoint (well not really because if you
>> can install a driver on a system all bets are off anyway) but it makes
> utilities
>> and such a bit harder to make.
>>
>> –
>> Bill McKenzie
>> Software Engineer - Prism 802.11 Wireless Solutions Conexant Systems,
>> Inc.
>>
>>
>> “Greg Jacklin” wrote in message news:xxxxx@ntdev…
>> > What should Driver Developers use instead of HalGetBusData.? Is
>> > there
> an
>> > example in the 2003 DDK? Something like the pcidump.sys driver example?
>> >
>> >
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as:
>> xxxxx@compuware.com To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>>
>>
>>
>> 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.
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@hotmail.com To
>> unsubscribe send a blank email to xxxxx@lists.osr.com
>>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> You are currently subscribed to ntdev as: xxxxx@stratus.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> You are currently subscribed to ntdev as: xxxxx@compuware.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
> 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.
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> You are currently subscribed to ntdev as: xxxxx@stratus.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> You are currently subscribed to ntdev as: xxxxx@stollmann.de
> To unsubscribe send a blank email to xxxxx@lists.osr.com
---- snip ----
Roddy, Mark wrote:
I absolutely agree alberto, it is your machine and you are free to do
anything you want with it.
…For consumers out there who just want their systems to work, I think Windows
remains a better choice, although my mom will indeed not be able to view PCI
bus config space.
Nor will the apps my Moms runs be able to view PCI bus config space,
which is even better!
Bravo, Mark. Your reply saved me from having to write mine. But then I
felt deprived, so I wrote a reply anyway…
Peter
OSR
They can do anything with their OS, I can do anything with my machine.
Including peek at the PCI bus. None of their business, and if the OS doesn’t
give me a way to do what I want, do what I want I will, regardless of the
OS.
So, long live SoftICE: it needs nothing but the bare iron. It reaches places
OS’s cannot reach.
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: Wednesday, July 28, 2004 10:57 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Substitute for HalGetBusData
I absolutely agree alberto, it is your machine and you are free to do
anything you want with it. Equally, it is Microsoft’s operating system, that
they have to support, and they can do anything they want with their
operating system.
I suggest that you not use Windows as an operating system as it is
constantly getting in the way of you doing your own thing. Linux, with its
complete source access and consequent ability for you to redesign it as you
see fit, would be a far better choice for you.
For consumers out there who just want their systems to work, I think Windows
remains a better choice, although my mom will indeed not be able to view PCI
bus config space.
=====================
Mark Roddy
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Wednesday, July 28, 2004 10:46 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Substitute for HalGetBusData
First, it’s my machine: not Microsoft’s. Second, the OS must not “in
charge”: it must be a helper and a facilitator. Third, it’s nobody’s
business to tell me what I will or will not do with my own machine.
It’s a *personal* computer, remember ? Otherwise, should we go back to the
mainframe culture of the 60’s ? I hope not.
So, I may want to write a program to see for myself what exactly each PCI
board is hogging. I may want to write a sample PCI enumerator driver to
expose my students to a read-only multiprocessor-aware entry-level piece of
kernel code. I may want to find my graphics board’s video memory so that my
diagnostic program can prod it and see if my graphics chip is working. I may
want to write a program that keeps tabs of what the OS is doing to my
hardware behind my back. I may want to time bus level events.
For example, once I had a problem passing WHQL with one of my OpenGL
drivers. It just happened that even though the OpenGL standard did not
demand that level of accuracy, the WHQL test would fail me if a fogged pixel
ended up having a 1/255 intensity as oposed to a 2/255 intensity: that’s one
pixel, mind you, in a whole window. Or it would fail me if my Bresenham drew
one of my line pixels at 371,478 instead of 370,478. So, I needed to tag my
pixels in video memory through some independent means, for example,
pre-drawing the line and using some ROP to highlight discrepancies, or
reading the fogged pixel from video memory and comparing it to the value I
expected to see. This code would be added to my OpenGL driver code, on the
fly. Well, to do that, I needed to access video memory, raw: I must find
where it is, make sure it’s mapped into some virtual memory page, and so on.
Or another example, a chip I worked with had a very peculiar texture format,
for performance reasons. To write a texture loader was a nontrivial task,
and debugging it was tough. The thing to do was again to write pixels to
video memory, by hand, and see if what we loaded matched it by running a
byte-by-byte compare, or just read the loaded texture back into host memory
and compare it: again, access to the wire was necessary.
I could go on. Production is just the tail end of a long and hard driver
development process, and to me as a kernel dev what matters is the level of
support the OS gives to my development activities: I’m a kernel dev, not an
IT manager.
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: Wednesday, July 28, 2004 9:50 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Substitute for HalGetBusData
Well I whole-hardidily disagree
That a *debugging* tool might need to access pci config space for devices it
is not managing is indeed true. That in general random kernel or user mode
components need to or rather should access pci config space for devices that
they are not managing is a very dubious proposition.
If in fact you are managing PCI busses rather than a PCI device on a bus
then write a PCI bus filter driver. If you aren’t managing PCI busses, and
you are not a debugger, why exactly do you think it is appropriate for your
program to be probing PCI config space?
I’d prefer to keep the programs accessing MY PCI device limited to my
driver, the PCI bus manager, and filter drivers using defined interfaces in
my device stack.
=====================
Mark Roddy
-----Original Message-----
From: Greg Jacklin [mailto:xxxxx@hotmail.com]
Sent: Tuesday, July 27, 2004 4:35 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Substitute for HalGetBusData
I whole hardidly agree with Alberto.
People will probe the PCI config space
whether or not windows believes they
should or not. If they DO expose a formal method for this then life would
be better for all ;-].
----- Original Message -----
From: “Moreira, Alberto”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, July 27, 2004 8:26 AM
Subject: RE: [ntdev] Substitute for HalGetBusData
> The problem of course is monitoring software, how do you keep an eye
> at
PCI
> space, how do you monitor changes ? If you can’t write software that
> reliably accesses the whole PCI space, you’re pretty much dooming a
> lot of low level debugging to hardware-only probing. And while I find
> it easy enough to put a few read-only bits in a bridge chip, I’m not
> sure I accept that forbidding reads to the PCI space enhances security
> that much. I believe that the OS should expose a spinlock to
> synchronize access to PCI bus space, and maybe lock whatever they will
> as read-only, but the last
word
> on what should be done in a machine must be the user’s, not the OS’s.
>
> Alberto.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Bill McKenzie
> Sent: Monday, July 26, 2004 11:30 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Substitute for HalGetBusData
>
>
> It depends on what you are trying to do. If all your driver needs is
access
> to the PCI config space of the PCI device that your driver controls,
> then you can follow the information in the following KB article:
>
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q253232
>
> If on the other hand your driver needs access to the PCI config space
> of other PCI devices then you would have to write a bus filter driver
> to
filter
> the PCI bus driver. This is not a trivial task.
>
> It seems that it was intended that a driver never touch the PCI
> configuration space of a device which it did not control. This makes
sense
> from a security/stability standpoint (well not really because if you
> can install a driver on a system all bets are off anyway) but it makes
utilities
> and such a bit harder to make.
>
> –
> Bill McKenzie
> Software Engineer - Prism 802.11 Wireless Solutions Conexant Systems,
> Inc.
>
>
> “Greg Jacklin” wrote in message news:xxxxx@ntdev…
> > What should Driver Developers use instead of HalGetBusData.? Is
> > there
an
> > example in the 2003 DDK? Something like the pcidump.sys driver example?
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@compuware.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
>
> 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.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hotmail.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
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.
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
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.
In case you haven’t noticed, SoftICE doesn’t need Windows to run. It talks
to the iron. So, maybe I already do what you suggest ?
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Norbert Kawulski
Sent: Wednesday, July 28, 2004 11:12 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Substitute for HalGetBusData
OooOOo. .oOOOo. oOoOOoOOo OOooOoO o o o .O o. o o O
O O O o o O o
o .O o O O oOooO o
OOooOO’ O o o O O
o o o O O o O
O O o O' O o o . O o OoooO’ o’ O’ OOoOooO
poor alberto …
Norbert.
I absolutely agree alberto, it is your machine and you are free to do
anything you want with it. Equally, it is Microsoft’s operating system,
that
they have to support, and they can do anything they want with their
operating system.
I suggest that you not use Windows as an operating system as it is
constantly getting in the way of you doing your own thing. Linux, with its
complete source access and consequent ability for you to redesign it as
you
see fit, would be a far better choice for you.
For consumers out there who just want their systems to work, I think
Windows
remains a better choice, although my mom will indeed not be able to view
PCI
bus config space.
=====================
Mark Roddy
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Wednesday, July 28, 2004 10:46 AM
To: Windows System Software Devs Interest List
Subject: RE: Substitute for HalGetBusData
First, it’s my machine: not Microsoft’s. Second, the OS must not “in
charge”: it must be a helper and a facilitator. Third, it’s nobody’s
business to tell me what I will or will not do with my own machine.
It’s a *personal* computer, remember ? Otherwise, should we go back to the
mainframe culture of the 60’s ? I hope not.
So, I may want to write a program to see for myself what exactly each PCI
board is hogging. I may want to write a sample PCI enumerator driver to
expose my students to a read-only multiprocessor-aware entry-level piece
of
kernel code. I may want to find my graphics board’s video memory so that
my
diagnostic program can prod it and see if my graphics chip is working. I
may
want to write a program that keeps tabs of what the OS is doing to my
hardware behind my back. I may want to time bus level events.
For example, once I had a problem passing WHQL with one of my OpenGL
drivers. It just happened that even though the OpenGL standard did not
demand that level of accuracy, the WHQL test would fail me if a fogged
pixel
ended up having a 1/255 intensity as oposed to a 2/255 intensity: that’s
one
pixel, mind you, in a whole window. Or it would fail me if my Bresenham
drew
one of my line pixels at 371,478 instead of 370,478. So, I needed to tag
my
pixels in video memory through some independent means, for example,
pre-drawing the line and using some ROP to highlight discrepancies, or
reading the fogged pixel from video memory and comparing it to the value I
expected to see. This code would be added to my OpenGL driver code, on the
fly. Well, to do that, I needed to access video memory, raw: I must find
where it is, make sure it’s mapped into some virtual memory page, and so
on.
Or another example, a chip I worked with had a very peculiar texture
format,
for performance reasons. To write a texture loader was a nontrivial task,
and debugging it was tough. The thing to do was again to write pixels to
video memory, by hand, and see if what we loaded matched it by running a
byte-by-byte compare, or just read the loaded texture back into host
memory
and compare it: again, access to the wire was necessary.
I could go on. Production is just the tail end of a long and hard driver
development process, and to me as a kernel dev what matters is the level
of
support the OS gives to my development activities: I’m a kernel dev, not
an
IT manager.
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: Wednesday, July 28, 2004 9:50 AM
To: Windows System Software Devs Interest List
Subject: RE: Substitute for HalGetBusData
Well I whole-hardidily disagree
That a *debugging* tool might need to access pci config space for devices
it
is not managing is indeed true. That in general random kernel or user mode
components need to or rather should access pci config space for devices
that
they are not managing is a very dubious proposition.
If in fact you are managing PCI busses rather than a PCI device on a bus
then write a PCI bus filter driver. If you aren’t managing PCI busses, and
you are not a debugger, why exactly do you think it is appropriate for
your
program to be probing PCI config space?
I’d prefer to keep the programs accessing MY PCI device limited to my
driver, the PCI bus manager, and filter drivers using defined interfaces
in
my device stack.
=====================
Mark Roddy
-----Original Message-----
From: Greg Jacklin [mailto:xxxxx@hotmail.com]
Sent: Tuesday, July 27, 2004 4:35 PM
To: Windows System Software Devs Interest List
Subject: Re: Substitute for HalGetBusData
I whole hardidly agree with Alberto.
People will probe the PCI config space
whether or not windows believes they
should or not. If they DO expose a formal method for this then life would
be better for all ;-].
----- Original Message -----
From: “Moreira, Alberto”
> To: “Windows System Software Devs Interest List”
> Sent: Tuesday, July 27, 2004 8:26 AM
> Subject: RE: Substitute for HalGetBusData
>> The problem of course is monitoring software, how do you keep an eye
>> at
> PCI
>> space, how do you monitor changes ? If you can’t write software that
>> reliably accesses the whole PCI space, you’re pretty much dooming a
>> lot of low level debugging to hardware-only probing. And while I find
>> it easy enough to put a few read-only bits in a bridge chip, I’m not
>> sure I accept that forbidding reads to the PCI space enhances security
>> that much. I believe that the OS should expose a spinlock to
>> synchronize access to PCI bus space, and maybe lock whatever they will
>> as read-only, but the last
> word
>> on what should be done in a machine must be the user’s, not the OS’s.
>>
>> Alberto.
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com]On Behalf Of Bill McKenzie
>> Sent: Monday, July 26, 2004 11:30 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] Substitute for HalGetBusData
>>
>>
>> It depends on what you are trying to do. If all your driver needs is
> access
>> to the PCI config space of the PCI device that your driver controls,
>> then you can follow the information in the following KB article:
>>
>> http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q253232
>>
>> If on the other hand your driver needs access to the PCI config space
>> of other PCI devices then you would have to write a bus filter driver
>> to
> filter
>> the PCI bus driver. This is not a trivial task.
>>
>> It seems that it was intended that a driver never touch the PCI
>> configuration space of a device which it did not control. This makes
> sense
>> from a security/stability standpoint (well not really because if you
>> can install a driver on a system all bets are off anyway) but it makes
> utilities
>> and such a bit harder to make.
>>
>> –
>> Bill McKenzie
>> Software Engineer - Prism 802.11 Wireless Solutions Conexant Systems,
>> Inc.
>>
>>
>> “Greg Jacklin” wrote in message news:xxxxx@ntdev…
>> > What should Driver Developers use instead of HalGetBusData.? Is
>> > there
> an
>> > example in the 2003 DDK? Something like the pcidump.sys driver
example?
>> >
>> >
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as:
>> xxxxx@compuware.com To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>>
>>
>>
>> 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.
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@hotmail.com To
>> unsubscribe send a blank email to xxxxx@lists.osr.com
>>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> You are currently subscribed to ntdev as: xxxxx@stratus.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> You are currently subscribed to ntdev as: xxxxx@compuware.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
> 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.
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> You are currently subscribed to ntdev as: xxxxx@stratus.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> You are currently subscribed to ntdev as: xxxxx@stollmann.de
> To unsubscribe send a blank email to xxxxx@lists.osr.com
---- snip ----
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
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.
Moreira, Alberto wrote:
In case you haven’t noticed, SoftICE doesn’t need Windows to run. It talks
to the iron. So, maybe I already do what you suggest ?
My moms is having trouble get her word processor to run on SoftIce to
write-up her recipes… Can you help?
Peter
OSR
I hesitate to disagree with this crowd, but I would enter one slight
exception. I am not suggesting that a driver be able to futz around in PCI
config space willy nilly, (but with PCI bus filters that is possible
anyway). What would be handy is if there were a way to get the contents of
config space from the PCI bus driver through a simpler mechanism, possibly
even from user-mode. This would be a read-only setup. That way, only the
PCI bus driver is accessing the config space, and we get to see what we
want. This would be very handy for diagnostic purposes and such. However,
I agree, it wouldn’t be useful for much else.
–
Bill McKenzie
Software Engineer - Prism 802.11 Wireless Solutions
Conexant Systems, Inc.
“PeterGV” wrote in message news:xxxxx@ntdev…
> Roddy, Mark wrote:
>
> > I absolutely agree alberto, it is your machine and you are free to do
> > anything you want with it.
> …
> >
> > For consumers out there who just want their systems to work, I think
Windows
> > remains a better choice, although my mom will indeed not be able to view
PCI
> > bus config space.
> >
>
> Nor will the apps my Moms runs be able to view PCI bus config space,
> which is even better!
>
> Bravo, Mark. Your reply saved me from having to write mine. But then I
> felt deprived, so I wrote a reply anyway…
>
> Peter
> OSR
>
>
>
Well, you can always write a filter driver.
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of PeterGV
Sent: Wednesday, July 28, 2004 12:30 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Substitute for HalGetBusData
Moreira, Alberto wrote:
In case you haven’t noticed, SoftICE doesn’t need Windows to run. It talks
to the iron. So, maybe I already do what you suggest ?
My moms is having trouble get her word processor to run on SoftIce to
write-up her recipes… Can you help?
Peter
OSR
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
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.
Also, you can use the Toaster.
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of PeterGV
Sent: Wednesday, July 28, 2004 12:30 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Substitute for HalGetBusData
Moreira, Alberto wrote:
In case you haven’t noticed, SoftICE doesn’t need Windows to run. It talks
to the iron. So, maybe I already do what you suggest ?
My moms is having trouble get her word processor to run on SoftIce to
write-up her recipes… Can you help?
Peter
OSR
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
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.