In message <19990707230648.d771...@overcee.netplex.com.au> Peter Wemm writes: : At the very least it must use the real resource lists, not a second copy. : That probably means that nexus.c itself would have to export these functions.
Yes. Or that bus_space_*map would live in nexus.c. : At the moment, the probe/attach routines use ia_iot from the aux arg: ... : .. using the isa stuff for an example. (tough if they want multiple : IO ports per device, eh? like the keyboard controller at 0x60 and 0x64 with : another device in between...) ok. : It uses the tag to get a handle: : And uses the tag and handle in the bus_space_read/write_xxx() macros. Hmmm. That may mean we'd have to make both bus_space_tag_t and bus_space_handle_t be structs. The bus_space_tag_t so that we know which device it is, and bus_space_handle_t to record the rid. Must ponder. : I don't see why we couldn't add a device_t pointer in there as well, and the : newconfig shim could use it to store the device_t of the wrapper device. Yes. Right now on NetBSD there is only one instance per bus type of the bus_space_tag structure, however. We'd have to have one per device_t that is wrapped. : The bus_space_map() etc macros could then do the proper uplink calls to the : parent bus since it now has access to the device pointer. Yes. That's true. Suddenly, a light has gone on in my head, so I'll try to code this up later this evening and see if the light was a good light, or a wil-o-the-wisp.[*] Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
