Kernel support for graphics cards

[olafBuddenhagen at gmx.net]

Hi,

> > The question isn't about moving all of the "X drivers" into kernel,
> > just about not poking around hardware directly, which I think
> > everyone agrees is a really bad idea.
> 
> they poke around by mmap()ing the video card and writing to memory -
> you can do this as root with lots of things. you need to have ROOT
> privelidges to do it though. the kernel cannto protect the registers
> unless it KNOWS what they mean and how they work - for that nvidia and
> ati and others will need to publish all their specs openly. if the
> kernel doesnt know what they mean - how is it to know somehting is a
> good or bad thing to do - and when? at the end of the day x is working
> with the gfx harward much like the kernel would - but form userspace
> instead, so it can segv. it basically expects to be the only thing
> fiddling with the gfx hw - within limits. like the kernel does with
> other hw (but the kernel ENFORCES such limits). until 1. gfx makers go
> open on specs so this can be implemented,

I think there is some misunderstanding here. The idea is *not* to have
the kernel put limits what kind of hardware access the userspace drivers
are allowed to do, using perfect knowledge of the hardware to decide
what is safe and what is not. The idea is rather for the kernel to do
the graphics hardware access *itself*, the userspace driver only telling
what operation it wants performed.

This doesn't require any more knowledge about the hardware than doing
the same access in userspace directly. The difference is that the kernel
driver can ensure that only known safe operations can be invoked. Thus,
it's actually a great advantage in case of incomplete specs.

> and 2. x and kernel coders sit down and work out how exactly to put it
> ALL in the kernel

As it turns out, "it ALL" isn't really that much. A typical KGI driver
(with accelaration support) is only a few kB -- not more than other
typical drivers.

There is nothing particularily complex about graphics hardware access.
What makes graphics drivers complex is the transformation of abstract
operations into specific commands that put the accelerator(s) to
(efficiently) perform the desired operation. We all seem to agree that
this part should (and can) be left in userspace.

(Preferably in a generic library, which can be used both by the X server
and by other interested parties.)

> (which would work only for linux btw - u'd need differnet drivers for
> bsd, etc. etc. etc.),

That's not necessarily true. In KGI, the board-specific driver modules
are actually system independant. It's in fact *more* portable than the
current situation, with kernel specific DRM drivers.

Of course, the interface for graphics hardware access needs to be hooked
into the kernel in a system specific fashion. Note however that hooking
it into the kernel requires *less* work than providing all the necessary
hooks for userspace drivers -- just look at the thread about PCI access.

BTW, the FreeBSD variant of KGI presently is actually more advanced than
the Linux implementation... :-)

-antrik-