"Eduardo E. Horvath" <eeh@one-o.com> writes:
> I will assert (again) that mapping the device registers is an inherently
> bus-specific operation and should be done by the driver through the use of
> bus_space*() routines rather than the VM system.

Yes.  The right interface to this is to have routines so that:

	* drivers can cause various of their bus spaces to be
	  'exportable' via mmap() and ioctl(),

	* a function to call from the driver's mmap entry point which
	  does the right thing in terms of translating offset into
	  physical addresses,

For complex spaces (or even 'generic access to normal spaces'), you'd
want a library in user-land to encapsulate this, which would provide
much of the same functionality as the existing bus_space
implementations, but based on the spaces exported via mmap() and
ioctl().

For simple flat (linear) frame buffers, i.e. what you can (and should)
currently map w/ the LINEAR flag (if you want to use it as a linear
region of memory), the corresponding functionality should be present
in the user-land library.  i.e. if you have a linear frame buffer, you
should end up being able to get a pointer to a buffer you can access
linearly.  (and, if you want to access it in a relatively
unsafe/unportable way, you can even map it via direct mmap() rather
than a call into the library which would end up doing the same thing.)



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.