In message <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
