[ On Wednesday, August 14, 2002 at 02:11:55 (+0200), der Mouse wrote: ]
> Subject: Re: Rehash: XFree86 Compiled on NetBSD/Sparc
>
> Not explicitly, but you espoused a viewpoint that requires it.

No, I'm sure I didn't suggest that all graphics operations would require
system calls (hopefully I implied quite the opposite), though perhaps
your pre-held assumptions about how such a device driver would/should
work may have made you think so.  ;-)

As I'm sure you know high speed, high throughput, devices can be
efficiently used either by employing DMA -- i.e. putting data in a range
of memory and telling the device to pull it out via direct bus access
without the use of the CPU (or vice versa to have the device dump data
directly into a specified range of memory without the direct assistance
of the CPU); or by mapping the device directly into some normal address
space that either the driver, and/or the application, can access as if
it were normal memory.  In neither case are system calls necessary to do
individual low-level operations, or even to move bulk data in or out of
a device.  Furthermore a driver could be configured to read streams of
operation codes out of a specified address space in the application
process and to send those code to a device as it's ready for them,
eg. via scheduled DMA requests, or on an interrupt, etc., with only an
occasional system call necessary to synchronise.

> That *is* just giving the user process direct access to the hardware,
> which is what I thought you were arguing against.  (I'm not sure what
> you're going on about DMA for, though.)  It exposes practically
> everything about the device to userland, with the possible exception of
> exactly where it lives in the machine's physical address space.

To _the_device_, well yes, of course.  That's the whole idea, isn't it?

The point is to prevent the application from having access to the bus
directly and to mediate certain critical operations through the driver
interface so that the authorized application is restricted to just the
one device and so that it doesn't have to run as root.  Perhaps not all
of the device is exposed to userland via address mapping -- just the
parts which must have high-speed access for good performance while all
the programming registers which control the mapping or DMA, etc. will
remain out of bounds to the process.

I.e. make it so you still have to ask the driver to map the device's
address space for your process, and/or if the device uses DMA then you
still may have to ask the driver to initiate DMA operations (though
perhaps write() calls are good enough if the kernel can do zero-copy
buffer management).  The device driver still controls all access to the
device, and presumably there are constraints in place so that the
application is not allowed to wander outside of whatever address ranges
might be necessary to access the device, or even just those portions of
the device which are safe to use from userland.  Obviously not all
hardware will be secure in this manner (perhaps there's no protection to
prevent the user from requesting that the device DMA some data over some
random memory location), but that's another implementation detail that
can be fixed (with help from the hardware vendors).

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>