Kernel support for graphics cards

[Carsten Haitzler (The Rasterman)]

On Mon, 09 Jan 2006 08:58:51 +1100 Bojan Smojver <bojan at rexursive.com> babbled:

> Quoting Carsten Haitzler <raster at rasterman.com>:
> 
> > i'd argue "why not" as well. but the kernel developers disagree. and i woudl
> > say that doing a gfx driver in userspace definitely makes for easier
> > development & debugging. :) also it means for better performance
> > characteristics of an OS if the gfx subsystem is doing some heavy software
> > fallbacks - the driver can be pre-empted trivially... like any process...
> > because... it is a process! :) seriously though - all that is really 
> > needed is
> > enough support hooks in the kernel to allow userspace gfx drivers - 
> > that's it.
> > and thats mostly there already.
> 
> I think there is some confusion here, probably related to the way I 
> asked the question (maybe even the subject line).
> 
> What I'm concerned about (and Keith's paper appears to be too) is the 
> fact that both the X and the kernels do things directly with the 
> graphics hardware. I sure wouldn't like my apps mucking around with 
> registers on my network card or SCSI controller without kernel's 
> approval first. So, the same should be true for graphics cards. And 
> because various systems can manipulate the same hardware resources, 
> many times in a completely uncoordinated fashion (IMHO, good 
> coordination should not be an excuse to keep things the way they are), 
> this then leads to "an application (X) rendered my system unusable" 
> problems (like it did in DOS days).
> 
> So, let me try again: my questions relate to making sure that X doesn't 
> drive the *hardware* directly (and I'm actually surprised modern 
> kernels allow it to do that all). 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, and 2. x and kernel coders sit down and work out how exactly to
put it ALL in the kernel (which would work only for linux btw - u'd need
differnet drivers for bsd, etc. etc. etc.), AND assuming they all agree (which
last i checked they all agreed that x is too complex to be in the kernel and
should always be left outside. gfx drivers are among the most complex drivers
on a system these days - in fact are by FAR the most complex, and due to their
special nature should be left out of the kernel)

so you have 1. a currently unsolvale techincal problem, 2. a viewpoint problem
that both x and kernel coders agree on to overcome, 3. a LOT of work to do to
desing a system thyat will work for everyone who needs it, 4. actually having
to implement it all.

i'd say you are pushing poo uphill here :)

> -- 
> Bojan
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)