INTRO (9) NetBSD Kernel Developer's Manual INTRO (9) NAME ...

BUS_SPACE(9) NetBSD Kernel Developer’s Manual BUS_SPACE(9)bus_space_read_stream_1(space , handle , offset)bus_space_read_stream_2(space , handle , offset)bus_space_read_stream_4(space , handle , offset)bus_space_read_stream_8(space , handle , offset)bus_space_read_multi_stream_1(space , handle , offset , datap , count)bus_space_read_multi_stream_2(space , handle , offset , datap , count)bus_space_read_multi_stream_4(space , handle , offset , datap , count)bus_space_read_multi_stream_8(space , handle , offset , datap , count)bus_space_read_region_stream_1(space , handle , offset , datap , count)bus_space_read_region_stream_2(space , handle , offset , datap , count)bus_space_read_region_stream_4(space , handle , offset , datap , count)bus_space_read_region_stream_8(space , handle , offset , datap , count)bus_space_write_stream_1(space , handle , offset , value)bus_space_write_stream_2(space , handle , offset , value)bus_space_write_stream_4(space , handle , offset , value)bus_space_write_stream_8(space , handle , offset , value)bus_space_write_multi_stream_1(space , handle , offset , datap , count)bus_space_write_multi_stream_2(space , handle , offset , datap , count)bus_space_write_multi_stream_4(space , handle , offset , datap , count)bus_space_write_multi_stream_8(space , handle , offset , datap , count)bus_space_write_region_stream_1(space , handle , offset , datap , count)bus_space_write_region_stream_2(space , handle , offset , datap , count)bus_space_write_region_stream_4(space , handle , offset , datap , count)bus_space_write_region_stream_8(space , handle , offset , datap , count)These functions are defined just as their non-stream counterparts, except that they provide no byte-ordertranslation.EXPECTED CHANGES TO THE BUS_SPACE FUNCTIONSThe definition of the bus_space functions should not yet be considered finalized. There are severalchanges and improvements which should be explored, including:• Providing a mechanism by which incorrectly-written drivers will be automatically given barriers andproperly-written drivers won’t beforced to use more barriers than they need. This should probably bedone via a #define in the incorrectly-written drivers. Unfortunately, atthis time, few drivers actuallyuse barriers correctly (or at all). Because of that, bus_space implementations on architectures whichdo buffering must always do the barriers inside the bus_space calls, to be safe. That has a potentiallysignificant performance impact.• Exporting the bus_space functions to user-land so that applications (such as X servers) have easier,more portable access to device space.• Redefining bus space tags and handles so that machine-independent bus interface drivers (for examplePCI to VME bridges) could define and implement bus spaces without requiring machine-dependent code.If this is done, it should be done in such a way that machine-dependent optimizations should remain possible.• Converting bus spaces (such as PCI configuration space) which currently use space-specific access methodsto use the bus_space functions where that is appropriate.• Redefining the way bus space is mapped and allocated, so that mapping and allocation are done with busspecific functions which return bus space tags. This would allow further optimization than is currentlypossible, and would also ease translation of the bus_space functions into user space (since mapping inuser space would look like itjust used a different bus-specific mapping function).NetBSD 3.0 March 1, 2008 17