a newbie question about READ_PORT_UCHAR

hi,
What is the correct place to use READ_PORT_UCHAR and READ_REGISTER_UCHAR
?
I saw in the sample of NTDDK\src\general\portio\sys\genport.c:

if (pLDI->PortMemoryType == 1) // Address is in I/O space
{

*(PUCHAR)pIOBuffer =
READ_PORT_UCHAR((PUCHAR)((ULONG_PTR)pLDI->PortBase + nPort) );

}
else if (pLDI->PortMemoryType == 0) // Address is in Memory space
{

*(PUCHAR)pIOBuffer =
READ_REGISTER_UCHAR((PUCHAR)((ULONG_PTR)pLDI->PortBase + nPort) );

}

but I can not found the code to assign pLDI->PortMemoryType = 0;
If a resource is transed from:
CmResourceTypePort ==> to CmResourceTypeMemory,
then which one should it use? READ_PORT_UCHAR or READ_REGISTER_UCHAR?
(I guest it should be READ_REGISTER_UCHAR, but I saw the sample in:
http://www.osr.com/files/Pci_wdm_v14.zip,
it always use READ_PORT_UCHAR, no metter which type it translated, so I
was a little confused)

Thanks.
Liang Ming-Chung

Yes, this remains less than well documented in the DDK, although see the DDK
section “Mapping Bus-Relative Addresses to Virtual Addresses”. If the raw
resource was initially CmResourceTypePort then you use PORT operations,
otherwise you use REGISTER operations. To decide which HAL call you use you
ignore the translated resource type.

-----Original Message-----
From: lmc83 [mailto:xxxxx@faraday.com.tw]
Sent: Tuesday, May 27, 2003 10:10 AM
To: NT Developers Interest List
Subject: [ntdev] a newbie question about READ_PORT_UCHAR

hi,
What is the correct place to use READ_PORT_UCHAR and READ_REGISTER_UCHAR
?
I saw in the sample of NTDDK\src\general\portio\sys\genport.c:

if (pLDI->PortMemoryType == 1) // Address is in I/O space
{

*(PUCHAR)pIOBuffer =
READ_PORT_UCHAR((PUCHAR)((ULONG_PTR)pLDI->PortBase + nPort) );

}
else if (pLDI->PortMemoryType == 0) // Address is in Memory space
{

*(PUCHAR)pIOBuffer =
READ_REGISTER_UCHAR((PUCHAR)((ULONG_PTR)pLDI->PortBase + nPort) );

}

but I can not found the code to assign pLDI->PortMemoryType = 0;
If a resource is transed from:
CmResourceTypePort ==> to CmResourceTypeMemory,
then which one should it use? READ_PORT_UCHAR or READ_REGISTER_UCHAR?
(I guest it should be READ_REGISTER_UCHAR, but I saw the sample in:
http://www.osr.com/files/Pci_wdm_v14.zip,
it always use READ_PORT_UCHAR, no metter which type it translated, so I
was a little confused)

Thanks.
Liang Ming-Chung


You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

“Roddy, Mark” wrote:

Yes, this remains less than well documented in the DDK, although see the DDK
section “Mapping Bus-Relative Addresses to Virtual Addresses”. If the raw
resource was initially CmResourceTypePort then you use PORT operations,
otherwise you use REGISTER operations. To decide which HAL call you use you
ignore the translated resource type.

Furthermore, you do not have to program your driver to cope with both of
them. You will know at the time you write your driver (because you’re
working closely with the hardware designers, right?) whether your device
is I/O or memory mapped. You *could* write your driver as flexibly as
the GENPORT sample is apparently written, but it would optional whether
you wanted that extra complexity.

Naturally, I think that the explanation pp. 373-78 of my WDM book is
crystal clear about all of this :slight_smile:


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

Mark,

I’m curious what makes you believe this. I know that there has been
plenty of confusion around this in the past. But all the HAL code that
I’ve written has assumed that, if you are assigned translated resources
that are in I/O space, then you will use READ_PORT* and if you are
assigned translated resources that are in memory space, you will call
READ_REGISTER*.

Can you site an example machine where you would need to do what you’ve
described? (I’m asking not because I think that you’re wrong, but
rather because I wonder whether somebody wrote a very confused HAL at
some point.)

  • Jake Oshins

-----Original Message-----
Subject: RE: a newbie question about READ_PORT_UCHAR
From: “Roddy, Mark”
Date: Tue, 27 May 2003 11:04:29 -0400
X-Message-Number: 25

Yes, this remains less than well documented in the DDK, although see the
DDK
section “Mapping Bus-Relative Addresses to Virtual Addresses”. If the
raw
resource was initially CmResourceTypePort then you use PORT operations,
otherwise you use REGISTER operations. To decide which HAL call you use
you
ignore the translated resource type.

-----Original Message-----
From: lmc83 [mailto:xxxxx@faraday.com.tw]
Sent: Tuesday, May 27, 2003 10:10 AM
To: NT Developers Interest List
Subject: [ntdev] a newbie question about READ_PORT_UCHAR

hi,
What is the correct place to use READ_PORT_UCHAR and
READ_REGISTER_UCHAR
?
I saw in the sample of NTDDK\src\general\portio\sys\genport.c:

if (pLDI->PortMemoryType == 1) // Address is in I/O
space
{

*(PUCHAR)pIOBuffer =
READ_PORT_UCHAR((PUCHAR)((ULONG_PTR)pLDI->PortBase + nPort) );

}
else if (pLDI->PortMemoryType == 0) // Address is in Memory
space
{

*(PUCHAR)pIOBuffer =
READ_REGISTER_UCHAR((PUCHAR)((ULONG_PTR)pLDI->PortBase + nPort) );

}

but I can not found the code to assign pLDI->PortMemoryType = 0;
If a resource is transed from:
CmResourceTypePort ==> to CmResourceTypeMemory,
then which one should it use? READ_PORT_UCHAR or
READ_REGISTER_UCHAR?
(I guest it should be READ_REGISTER_UCHAR, but I saw the sample in:
http://www.osr.com/files/Pci_wdm_v14.zip,
it always use READ_PORT_UCHAR, no metter which type it translated,
so I
was a little confused)

Thanks.
Liang Ming-Chung

Walter,

You may know when talking to your hardware folks whether the device
appears in I/O or memory space. But you don’t know at that time what
machines it will be plugged into. Lots of non-X86 machines map I/O into
memory space, which requires using the READ_REGISTER* functions. Even
some IA-64 machines have this property.

  • Jake Oshins

-----Original Message-----
Subject: Re: a newbie question about READ_PORT_UCHAR
From: Walter Oney
Date: Tue, 27 May 2003 12:00:19 -0400
X-Message-Number: 28

“Roddy, Mark” wrote:
> Yes, this remains less than well documented in the DDK, although see
the DDK
> section “Mapping Bus-Relative Addresses to Virtual Addresses”. If the
raw
> resource was initially CmResourceTypePort then you use PORT
operations,
> otherwise you use REGISTER operations. To decide which HAL call you
use you
> ignore the translated resource type.

Furthermore, you do not have to program your driver to cope with both of
them. You will know at the time you write your driver (because you’re
working closely with the hardware designers, right?) whether your device
is I/O or memory mapped. You could write your driver as flexibly as
the GENPORT sample is apparently written, but it would optional whether
you wanted that extra complexity.

Naturally, I think that the explanation pp. 373-78 of my WDM book is
crystal clear about all of this :slight_smile:


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

Jake Oshins wrote:

You may know when talking to your hardware folks whether the device
appears in I/O or memory space. But you don’t know at that time what
machines it will be plugged into. Lots of non-X86 machines map I/O into
memory space, which requires using the READ_REGISTER* functions. Even
some IA-64 machines have this property.

That’s pretty big news, Jake! It flies in the face of everything that’s
been written by us outsiders about how to program drivers. Heretofore, I
(and every other author) had assumed that these non-X86 machines had
HAL’s that would do memory references when called at the PORT entries.


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

Walter Oney wrote:

That’s pretty big news, Jake! It flies in the face of everything that’s
been written by us outsiders about how to program drivers. Heretofore, I
(and every other author) had assumed that these non-X86 machines had
HAL’s that would do memory references when called at the PORT entries.

I meant to say it “invalidates everything that’s been written”. Anyway,
this calls for a banner headline somewhere, because there are *lots* of
broken drivers out there.


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

When we at Microsoft write the OS code, our point of view is that the
translated resources are always the last word. There is no reason to look
at the raw resources if you’re writing the FDO for a PCI device. The raw
resources (which I would have named “bus-relative,” rather than “raw”) are
interesting only to the bus driver. The translated resources (which I would
have named “processor-relative”) are the final word on how to access the
device from the processor.

You got me wondering. So I started searching in the DDK. So far, I found
this in the text about starting a device:

If a driver is assigned a translated memory resource (CmResourceTypeMemory),
it must call MmMapIoSpace to map the physical address into a virtual address
through which it can access device registers. For a driver to operate in a
platform independent manner, it should check each returned, translated
resource and map it, if necessary.

I admit that that’s not much to go on. There might be something better in
there that is eluding my ability to find it.

There has been confusion for years around this topic, which is why current
HALs try to deal with memory mapped I/O ports by handing back cookies that
represent the memory ranges. Then the driver gets translated resources that
are I/O ports, but which are not the same as the bus-relative (raw) I/O
ports. Then the HAL manages the mappings as you call READ_PORT* and
WRITE_PORT*. This is particularly necessary when the I/O to memory mapping
is dense to sparse, since drivers will assume that adding one to a base port
address will actually return the next successive port.

This technique doesn’t always work, though, particularly in machines that
have very large physical address spaces. So sometimes the HAL will just
expose the I/O mapping as a memory range. This has been done in most of the
non-x86 HALs that have ever been written. The Alphas were an interesting
exception. Up until the EV6, the Alpha couldn’t read and write individual
bytes. All loads and stores were 64-bit. So they mapped their PCI memory
space as dense to sparse, which meant that it was impossible for a driver to
deal with memory at all in a portable manner, since drivers will often just
map structures across known memory ranges. So even memory resources on
those machines would end up as “I/O ports,” complete with I/O as the
translated resource type and a set of resources that represented cookies in
the HAL.

IA-64 (Itanium) is an interesting case, too. It maps bus-relative I/O into
processor-relative memory, sparsely. There is a register in the processor
that points to the base of the memory range were I/O lives, so that “I/O”
instructions just work. But it only works for a single 64K I/O range. If
you build a machine with more than one sparse 64K I/O range (and people
certainly do that) then you have to read and write the secondary I/O spaces
with memory loads and stores. In order to do this, the HAL hands out
cookies for these secondary spaces, allowing the translated resources to be
I/O in all cases. The funny part comes when you consider that some busses
will have ports where raw==translated and some won’t. Accesses to the
secondary busses are also a little slower, since the HAL has to unpack the
cookie and resolve it every time.

If somebody builds an IA-64 machine with a secondary 64K I/O range that has
a bus-relative I/O to processor-relative memory mapping that is dense to
dense, the cookie scheme breaks down. At that point the HAL will create
translated resources that are memory in this case, and the drivers will have
to read the READ_REGISTER* functions. I have not actually seen a machine
that does this, though I have simulated one in the lab, to be sure that my
HAL code works.

  • Jake Oshins

“Walter Oney” wrote in message news:xxxxx@ntdev…
>
> “Roddy, Mark” wrote:
> > Yes, this remains less than well documented in the DDK, although see the
DDK
> > section “Mapping Bus-Relative Addresses to Virtual Addresses”. If the
raw
> > resource was initially CmResourceTypePort then you use PORT operations,
> > otherwise you use REGISTER operations. To decide which HAL call you use
you
> > ignore the translated resource type.
>
> Furthermore, you do not have to program your driver to cope with both of
> them. You will know at the time you write your driver (because you’re
> working closely with the hardware designers, right?) whether your device
> is I/O or memory mapped. You could write your driver as flexibly as
> the GENPORT sample is apparently written, but it would optional whether
> you wanted that extra complexity.
>
> Naturally, I think that the explanation pp. 373-78 of my WDM book is
> crystal clear about all of this :slight_smile:
>
> –
> Walter Oney, Consulting and Training
> Basic and Advanced Driver Programming Seminars
> Check out our schedule at http://www.oneysoft.com
>
>

Jake Oshins wrote:

If a driver is assigned a translated memory resource (CmResourceTypeMemory),
it must call MmMapIoSpace to map the physical address into a virtual address
through which it can access device registers. For a driver to operate in a
platform independent manner, it should check each returned, translated
resource and map it, if necessary.

I’ll bet that most readers of this would have assumed that the writer
just forgot to mention CmResourceTypePort with the CM_RESOURCE_PORT_IO
flag set to zero.

Frankly, I think the true state of affairs creates horrible complication
for driver programmers, not to mention undesirable conditional logic in
high-performance code paths. The whole point of the HAL is to insulate
programmers from platform details, right?

But thanks for the clarification, as much work as it means for all of us
out here.


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

I’ve spent much of the last day discussing this with various people. The
issue boils down to several parts; architecture, history and pragmatism.

Architecture:

The correct architectural answer from the point of view of the people who
design and build this stuff at Microsoft (which amounts to me and a few
others) is that the translated resources are the final word on the subject.
If your translated resources contain a memory resource, you must map it with
MmMapIoSpace and you must use READ_REGISTER* and WRITE_REGISTER* functions.
If your translated resource is an I/O port resource, you do not need to map
it, and you call READ_PORT* and WRITE_PORT*. This has always been true.
And it will continue to be true.

This, of course, implies that you must be prepared to access I/O port-based
hardware with either READ_PORT* or READ_REGISTER* functions. This is
unfortunate, since it involves either having two copies of the hardware
access functions, or having one copy with a bunch of conditional branching.
I personally would suggest having two copies, and to call them via a
function table which you set up when you acquire your resources.

You might be asking at this point (quite justifiably) why we at Microsoft
don’t simplify this for you by doing the mapping behind the scenes and
handing out “cookie” resources that are I/O ports. Then, when the driver
calls READ_PORT*, the HAL will use the cookie to figure out what access has
to be done, and then just do it. The answer is that some Alpha machines,
and more importantly, some IA-64 machines simply have a set of possible
address spaces and possible dense to sparse mappings such that all the
possibilities just can’t be represented in a cookie that is the same size as
a pointer. If the READ_PORT* functions had any other parameters, like a
device object, (or anything else really,) we could tie a specific device’s
requests back to its assigned resources, and that would allow us to
automatically handle the mappings for you. This would also, of course, add
a lot of overhead in the read and write paths. It might also preclude
allowing you to map data structures across your memory-mapped hardware,
which is useful for some implementations.

History:

Several people have observed that the MIPS defined READ_PORT* as simple
memory accesses, right there in ntddk.h. (The same was true of PowerPC,
though nobody bothered to point that out to me.) Thus the advice given in
Walter’s book, and in Peter’s old NT Insider article, worked perfectly well.
While this was true, it was not an architectural choice, it was something
that the owners of those processor architectures did in order to simplify
their implementations a little bit, and to make a few
architecturally-challenged drivers work anyhow. (They would also
opportunistically map port space, so that drivers which failed to would
still work. This worked well in simple machines.) In the same timeframe
that these machines were in use, there were x86-based machines from
Corollary and NCR that required the architecture described above, since they
mapped I/O into processor-relative memory space for secondary root busses.

Pragmatism:

Given that there are now many thousands of drivers that have been written
the way the Walter, Peter and others have taught people to do it, and given
that very, very few of you will ever interact with a modern machine that
excercises anything but the simple I/O equals I/O codepaths, we at Microsoft
will make every effort to make your drivers just work. It’s now true that
only the very highest-end machines (those capable of at least 32 processors)
need to map I/O into memory space. This is partly because the processors
that are in use today implement native or near-native I/O space. It’s also
partly because PCI-X and PCI-Express require that all devices expose their
registers in memory space, even when they also expose them in I/O space.
This allows modern machine vendors to provide just a single 64K I/O space.
There are even vendors who are considering dropping I/O space completely.

Aside: There was only one set of machines that mapped bus-relative memory
space into processor-relative “I/O” space. Those were the Alpha pre-EV6’s.
Those are gone now, thank god.

There are currently no machines that I know of that run Windows Server 2003
that require any translation of resource types. (There are at least a few
that require translations from one base address to another, but not from I/O
to memory.) So, if I were a driver writer out there, I’d probably look back
at the drivers that I’ve written and decide that they don’t need to be
revisited. If I were thinking about future work, I might decide to do a
function-table implementation. But even that is a hard call, since you
probably won’t be able to find any machines to test your code on.

For my part, I’ll do my best to convince the various machine makers that
they don’t really want to (re-)introduce bus architectures that require the
really complex mappings. Some of them listen to me when I say these things
and some don’t.

I’ll also convince the people here at Microsoft who are working on the
Driver Framework that they should provide support routines that handle the
problem in an architecturally correct manner, so that those of you who move
to the Framework in the future really won’t have to worry about it.

“Walter Oney” wrote in message news:xxxxx@ntdev…
>
> Jake Oshins wrote:
> > If a driver is assigned a translated memory resource
(CmResourceTypeMemory),
> > it must call MmMapIoSpace to map the physical address into a virtual
address
> > through which it can access device registers. For a driver to operate in
a
> > platform independent manner, it should check each returned, translated
> > resource and map it, if necessary.
>
> I’ll bet that most readers of this would have assumed that the writer
> just forgot to mention CmResourceTypePort with the CM_RESOURCE_PORT_IO
> flag set to zero.
>
> Frankly, I think the true state of affairs creates horrible complication
> for driver programmers, not to mention undesirable conditional logic in
> high-performance code paths. The whole point of the HAL is to insulate
> programmers from platform details, right?
>
> But thanks for the clarification, as much work as it means for all of us
> out here.
>
> –
> Walter Oney, Consulting and Training
> Basic and Advanced Driver Programming Seminars
> Check out our schedule at http://www.oneysoft.com
>
>

Jake,

Given that the semantics of READ/WRITE_*BUFFER* operations are different
(or at least they used to be different, maybe that has changed too,)
depending on PORT vs REGISTER, the “new revised astounding correct way to do
this” is rather annoying.

-----Original Message-----
From: Jake Oshins [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, May 30, 2003 4:12 PM
To: NT Developers Interest List
Subject: [ntdev] Re: a newbie question about READ_PORT_UCHAR

I’ve spent much of the last day discussing this with various people. The
issue boils down to several parts; architecture, history and pragmatism.

Architecture:

The correct architectural answer from the point of view of the people who
design and build this stuff at Microsoft (which amounts to me and a few
others) is that the translated resources are the final word on the subject.
If your translated resources contain a memory resource, you must map it with
MmMapIoSpace and you must use READ_REGISTER* and WRITE_REGISTER* functions.
If your translated resource is an I/O port resource, you do not need to map
it, and you call READ_PORT* and WRITE_PORT*. This has always been true. And
it will continue to be true.

This, of course, implies that you must be prepared to access I/O port-based
hardware with either READ_PORT* or READ_REGISTER* functions. This is
unfortunate, since it involves either having two copies of the hardware
access functions, or having one copy with a bunch of conditional branching.
I personally would suggest having two copies, and to call them via a
function table which you set up when you acquire your resources.

You might be asking at this point (quite justifiably) why we at Microsoft
don’t simplify this for you by doing the mapping behind the scenes and
handing out “cookie” resources that are I/O ports. Then, when the driver
calls READ_PORT*, the HAL will use the cookie to figure out what access has
to be done, and then just do it. The answer is that some Alpha machines,
and more importantly, some IA-64 machines simply have a set of possible
address spaces and possible dense to sparse mappings such that all the
possibilities just can’t be represented in a cookie that is the same size as
a pointer. If the READ_PORT* functions had any other parameters, like a
device object, (or anything else really,) we could tie a specific device’s
requests back to its assigned resources, and that would allow us to
automatically handle the mappings for you. This would also, of course, add
a lot of overhead in the read and write paths. It might also preclude
allowing you to map data structures across your memory-mapped hardware,
which is useful for some implementations.

History:

Several people have observed that the MIPS defined READ_PORT* as simple
memory accesses, right there in ntddk.h. (The same was true of PowerPC,
though nobody bothered to point that out to me.) Thus the advice given in
Walter’s book, and in Peter’s old NT Insider article, worked perfectly well.
While this was true, it was not an architectural choice, it was something
that the owners of those processor architectures did in order to simplify
their implementations a little bit, and to make a few
architecturally-challenged drivers work anyhow. (They would also
opportunistically map port space, so that drivers which failed to would
still work. This worked well in simple machines.) In the same timeframe
that these machines were in use, there were x86-based machines from
Corollary and NCR that required the architecture described above, since they
mapped I/O into processor-relative memory space for secondary root busses.

Pragmatism:

Given that there are now many thousands of drivers that have been written
the way the Walter, Peter and others have taught people to do it, and given
that very, very few of you will ever interact with a modern machine that
excercises anything but the simple I/O equals I/O codepaths, we at Microsoft
will make every effort to make your drivers just work. It’s now true that
only the very highest-end machines (those capable of at least 32 processors)
need to map I/O into memory space. This is partly because the processors
that are in use today implement native or near-native I/O space. It’s also
partly because PCI-X and PCI-Express require that all devices expose their
registers in memory space, even when they also expose them in I/O space.
This allows modern machine vendors to provide just a single 64K I/O space.
There are even vendors who are considering dropping I/O space completely.

Aside: There was only one set of machines that mapped bus-relative memory
space into processor-relative “I/O” space. Those were the Alpha pre-EV6’s.
Those are gone now, thank god.

There are currently no machines that I know of that run Windows Server 2003
that require any translation of resource types. (There are at least a few
that require translations from one base address to another, but not from I/O
to memory.) So, if I were a driver writer out there, I’d probably look back
at the drivers that I’ve written and decide that they don’t need to be
revisited. If I were thinking about future work, I might decide to do a
function-table implementation. But even that is a hard call, since you
probably won’t be able to find any machines to test your code on.

For my part, I’ll do my best to convince the various machine makers that
they don’t really want to (re-)introduce bus architectures that require the
really complex mappings. Some of them listen to me when I say these things
and some don’t.

I’ll also convince the people here at Microsoft who are working on the
Driver Framework that they should provide support routines that handle the
problem in an architecturally correct manner, so that those of you who move
to the Framework in the future really won’t have to worry about it.

“Walter Oney” wrote in message news:xxxxx@ntdev…
>
> Jake Oshins wrote:
> > If a driver is assigned a translated memory resource
(CmResourceTypeMemory),
> > it must call MmMapIoSpace to map the physical address into a virtual
address
> > through which it can access device registers. For a driver to
> > operate in
a
> > platform independent manner, it should check each returned,
> > translated resource and map it, if necessary.
>
> I’ll bet that most readers of this would have assumed that the writer
> just forgot to mention CmResourceTypePort with the CM_RESOURCE_PORT_IO
> flag set to zero.
>
> Frankly, I think the true state of affairs creates horrible
> complication for driver programmers, not to mention undesirable
> conditional logic in high-performance code paths. The whole point of
> the HAL is to insulate programmers from platform details, right?
>
> But thanks for the clarification, as much work as it means for all of
> us out here.
>
> –
> Walter Oney, Consulting and Training
> Basic and Advanced Driver Programming Seminars
> Check out our schedule at http://www.oneysoft.com
>
>


You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Jake Oshins wrote:

I’ve spent much of the last day discussing this with various people. The
issue boils down to several parts; architecture, history and pragmatism.

Again, thanks. But what about the CM_RESOURCE_PORT_IO flag? I’ve been
teaching people to call MmMapIoSpace if that’s false (for a “port”
resource, that is). Since you didn’t mention it, I have to assume it’s
either always set or that the mapping call wouldn’t solve the problem
you’re talking about.


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

You wrote :

You might be asking at this point (quite justifiably) why we at Microsoft
don’t simplify this for you by doing the mapping behind the scenes and
handing out “cookie” resources that are I/O ports. Then, when the driver
calls READ_PORT*, the HAL will use the cookie to figure out what access has
to be done, and then just do it.

My opinion is that software writers always suspect the “black boxes” at first sight if they
encounter a problem. And more, a device driver writer has many times to deal with
prototype hardware form which he may expect there could be still hardware bugs or
“strange” behaveours, which obliges him to know how to access the hardware. Be able
to understand what is is behind the READ_PORT, READ_REGISTER is a faster way to
trace ( find ) bugs in own software and hardware than making correct or false assumptions
on a “black box”. Think about tracing the HW access by means of logic analyzer and only
seeing the instructions the “black box” is generating for you …

That flag is not meaningful. I believe that it was used as a translation
hint in the Alpha HALs. No current code uses it.


Jake Oshins
Windows Base Kernel Team

This posting is provided “AS IS” with no warranties, and confers no rights.
OR if you wish to include a script sample in your post please add “Use of
included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

“Walter Oney” wrote in message news:xxxxx@ntdev…
>
> Jake Oshins wrote:
> > I’ve spent much of the last day discussing this with various people.
The
> > issue boils down to several parts; architecture, history and pragmatism.
>
> Again, thanks. But what about the CM_RESOURCE_PORT_IO flag? I’ve been
> teaching people to call MmMapIoSpace if that’s false (for a “port”
> resource, that is). Since you didn’t mention it, I have to assume it’s
> either always set or that the mapping call wouldn’t solve the problem
> you’re talking about.
>
> –
> Walter Oney, Consulting and Training
> Basic and Advanced Driver Programming Seminars
> Check out our schedule at http://www.oneysoft.com
>
>