The Windows Developer's Digest
Letters from Our Readers
I.A.: If I read [Mark Roddy's article "Accessing Hardware Registers" (WD-3, July 15, 2003)], a CmResourceTypePort resource will still remain as such in the raw resources, even if it could have become a CmResourceTypeMemory resource in the translated version. This means one could still sanity check that the resource is using the correct address space at the physical bus level if one wants to, as long as one knows the expected order of the various port/memory resources.
Mark Roddy replies: You read the article correctly. The raw resource should always reflect the hardware device configuration. For PCI bus devices, you can safely assume that the resource list order presented in start device reflects the valid bar order for your device's config space. (Unused bars are omitted.)
G.S.: I read [Bill McKenzie's] article[s] about 1394 Address allocation and asynchronous transfer and one this is still not clear to me that. If you have two PC's using XP are connected back to back, which will be host, whose memory will used in address allocation. And how they will transfer data. Or one computer writes to memory of other (responder) and vice versa.
Bill McKenzie replies: Each node has its own 256 TB address space on the 1394 bus. Every asynchronous transfer is initiated from a single node on the bus to the address space of another node on the bus. Actual physical memory usage is dependent on the node. If your driver allocates a range in the host controller's address space, for example, then your driver will provide the backing store or memory used for that address range. Other than that the host controller manages its own address space and provides backing store where needed/desired. Other nodes provide their own physical memory of some type. Most nodes obviously won't provide backing store for the entire 256TB address space provided to them. In that case, the node could provide a default, or just return a failing status in the asynchronous response packet. This last point I may have failed to state anywhere actually.
As far as two XP computers hooked together, each host controller will be a node on the 1394 bus, and will have its own 1394 address space, how that is backed by memory is completely up to the host controller nodes themselves, which ultimately means the 1394 bus driver stack handles it.
You need to understand that 1394 and USB are similar only in the fact that they are both high speed serial busses. All similarities pretty well break down from there. 1394 is a peer-to-peer bus, it does not have the host-target model of USB. Two 1394 connected 1394 host controllers are peers, neither is host. Some bus resources, such as isochronous bandwidth, are managed by a node acting as isochronous resource manager. However, which node is the isochronous resource manager can change upon any bus reset and it does not give that node any precedence or control in the actual communication flow. All nodes are still peers. Any node can initiate a transfer to any other node, and does not need a host to go through.
Click on this link to write us.
It seems that a driver programmer and a marketing VP were both slated to be guests of honor at the guillotine. The marketing VP had promised the customer their driver could be delivered in three weeks, which (of course) wasn't enough time for the driver programmer to develop it. They were both to be executed per the terms of the development contract's penalty clause, which was unwisely agreed to by the VP.
At the appointed time, they were brought to the guillotine platform. As they were led up the stairs to be dispatched, the driver programmer whispered to the VP, "When I tell you to, jump as high as you can and grab my ponytail." Startled, the VP said, "What are you talking about?" "Just do it!", hissed the driver programmer. When they reached the top of the stairs, the driver programmer began quickly rotating his head, causing the locks of his ponytail to spin. "Now!" shouted the driver programmer.
The VP jumped into the air and grabbed the driver programmer's spinning ponytail. Immediately, much to the VP's surprise, the entire structure began to fall apart, crashing to the ground. The driver programmer and the VP escaped in the confusion.
When they were a safe distance away, they stopped to rest. "What happened back there?", the VP panted. Smiling, the driver programmer said, "Every good driver developer knows the platform crashes when you grab spin locks when above dispatch level."
Daniel E. Germann
Guidelines for Letters from Our Readers
Please follow these guidelines in submitting letters to us:
Keep it technical! We'll love to read flattering comments about WD-3 and our own selves, but we assume you readers would be bored to tears. So forgive us for not reprinting letters that just tell us that WD-3 is the best thing since sliced bread. Or not.
Keep it polite! Please, no personal flames or insinuations that authors or editors are dumb as a trilobite.
Keep it relevant! Please don't respond to an article about USB enumeration by going off on a tangent about how much better 1394 is. Write your own article, and maybe we'll print it.
Keep it noncommercial! We intend to be totally noncommercial, so we won't print product reviews (positive or negative) dressed up as comment.
Finally, bear in mind that we reserve the right to print or not print any letter based on our own arbitrary judgment of how relevant it will be to our readers.