X servers talking directly to frame buffers generally use code that is
generated directly from some very "interesting" macros, that is carefull
about alignment issues in the first place. The portable X frame buffer
code is one of the more interesting pieces of code around, particularly
once you realize the same source file generates a bunch of other .c files
that actually do the work. They certainly do not do function calls (or
even invoke other macros) to "do the right thing".
> >
> > Hmmm, good point - I wonder how the XFree people solved this for the
> > Alpha X servers.
> Well, how does this fit with the point that user space IO memeory access
> is bad? Sure enough X11 is all based on this "bad" concept.
Lesser of several evils; putting all the graphics code required in a window
system into the kernel is much worse (particularly due to the schedular
problems it would generate; a bit blit of a large area of the screen is
not something you want to do without pre-emption). People went there
in the 1980's, tried it, and didn't like it... The graphics performance
requirements are also very high; the system call boundary is a problem.
I've never seen it as a real problem from an architecture point of view
that certain hardware may be mapped where user space programs can access
it directly, presuming the hardware itself is not going to compromise the
integrity of the system (certainly true for alot of graphics hardware).
But then again, I'm biased...
- Jim Gettys
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/