From owner-freebsd-hackers Wed Jul 7 19: 0:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 2776F154E3 for ; Wed, 7 Jul 1999 19:00:10 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id UAA27107; Wed, 7 Jul 1999 20:00:00 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id TAA05546; Wed, 7 Jul 1999 19:57:41 -0600 (MDT) Message-Id: <199907080157.TAA05546@harmony.village.org> To: Peter Wemm Subject: Re: The busspace modernization initiative. Cc: Doug Rabson , hackers@freebsd.org In-reply-to: Your message of "Thu, 08 Jul 1999 07:06:48 +0800." <19990707230648.D771A78@overcee.netplex.com.au> References: <19990707230648.D771A78@overcee.netplex.com.au> Date: Wed, 07 Jul 1999 19:57:41 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990707230648.D771A78@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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message