On Fri, Mar 12, 2010 at 08:58:11PM +0100, Matthias Drochner wrote: > > [pci bus space alloc] > dyo...@pobox.com said: > > > The new methods should be part of the pci(9) API. That kind of > > > bus space management is inherently bus specific. > > Do you think that bus_space_alloc(9) should go away, then? > > It shouldn't go away, it it needed where the MI pci hierarchy meets > MD semantics, at the host bridge. > > For me, bus_space_* and the bus_addr_t types refer to a platforms > native "main bus" which is basically what comes out of the MMU. > MI buses should use fixed width types to describe their interfaces.
According to my understanding of bus_space(9), bus_addr_t alone can unambiguously describe an address on the target bus, from the perspective of all of the agents directly connected to that bus. Only the tuple [bus_space_handle_t, bus_addr_t] unambiguously describes the same address from the perspective of the CPU, however. bus_space_tag_t tells us what the target bus is, and how to operate on it. Does that sound about right to you? > > And what about bus_space_map(9)? > > Here is the question whether we want to support PCI where it is not > a "native" bus and mapped by a MD host bridge. Let's say "maybe someday." :-) I'm interested in accessing a PCI bus over IEEE 1394. > > Certainly I could introduce pci_space_alloc(9) with a similar signature > > as bus_space_alloc(). > > There is no guarantee anyway that eg. the PCI I/O space corresponds > to an I/O space known to bus_space_alloc()... I think that in that case we will have no bus_space_tag_t for PCI I/O space. How will problems arise for bus_space_alloc()? Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
