[ On , July 17, 2001 at 00:48:08 (-0400), Nathan J. Williams wrote: ]
> Subject: Re: Why not track our xsrc with X11R6.6 from X.org?
>
> Even the "simple" problem of providing information about the frame
> buffer sizes and control register locations requires kernel knowledge
> of the video card.

yes, of course, that part I do understand....

> The problem with the PC-world PCI/AGP video card universe is that
> there are 10 bazillion cards and variants, and every single one is
> annoyingly different.

Hmmmm...  indeed....

> Do you really want to have to make the kernel know about all this
> goop so that it can translate it into a common interface? 

It's got to be somewhere, right?  It's (much) safer in the kernel.

Obviously even with the narrowing numbers of unix variants it would
still be nice to have a firmer DDI/DKI specification so that fewer
variants of drivers need be written, but even without it would seem that
if whomever does the common X coding can provide template drivers
that'll be easy enough for non-X11 systems programmers to munge into
their specific operating systems (and the remaining commercial vendors
can use them too! ;-).

> This is not to say that XFree86 is the model of ideal software
> portability; just that the appropriate abstraction layer is
> lower.

which is what's wrong and "pc-centric" and insecure about it (besides
also being non-portable and in-elegant).

> Something like "What kind of bus is this on? What is the
> bus-specific information (TC/SBus/PCI device ID, and so on)? For some
> buses, "What address ranges can I map?". 

this is where it goes from being merely ugly to being down-right horrid
and gross.  it grates against my very nerves!  and its very in-elegant
too -- now we've got user-land code apparently duplicating much of the
low-level hardware probing and mapping done initially by the kernel!

At the very worst couldn't there be a common interface defined such that
a virtual device driver (or sysctl, or /kern file, or whatever) could
provide all the necessary details in some mostly portable manner?

> This also doesn't even touch the (hardware-based) issue that the
> implementation of accelerated video cards with DMA engines, and the
> lack of page-based protection in any computer's bus/memory DMA
> interface, implies that any code that can touch the video system in a
> useful way has full priveleges to touch the entire system.

Why?  Is it just because of brain-dead hardware design, or lazy driver
design, or is it simply impossible to fix properly?  Why can't the
driver be in control of (and thus vetting) the DMA operations?

Performance isn't everything!  Surely we can have decent performance
with the kernel still in control of the dangerous bits with sharp
corners!  The human eye can only perceive things at a certain rate --
beyond that everything's surplus/wasted anyway!  Some people might not
be happy until they can run Final Fantasy's rendering in real time, but
I'd argue they shouldn't be using X11 to display it in the first place!
Those of us who just want to use normal X11 stuff and do the occasional
multi-media presentation of pre-canned renderings don't want all the
complex Xserver code to be potentially in full control of *all* our
hardware (we already have a complex unix kernel to do that :-)!

-- 
							Greg A. Woods

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