[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. > 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. I don't see any hardware support which could do this in NetBSD currently, but there are some ways to connect a PCI bus hierarchy to an MI bus: -Some PCI-VME bridges can be used the other way - controlling a PCI bus from VME. Haven't tried that. -remote PCI bus mastering through 1394/firewire -InfiniBand In these cases, the PCI bus isn't just mapped 1:1 to the mainbus, but through a bridge which does some translation. So one can also connect a bus with a larger address width to a 32-bit system with 32-bit bus_addr_t. > 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've tried to get that abstraction clean for VME bus support a while ago. Have a look at dev/vme/vmevar.h. best regards Matthias ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------
