Every chipset is handled by a single module, which can either be compiled
in statically, or loaded as needed. You -don't- carry the bulk of
everything in the kernel. "libggi" provides a uniform interface if you
need it (which most applications are perfectly acceptable under), but KGI
and the associated modules provide as low-level an interface as security
and stability will allow, should it be necessary.
That's the whole point behind the differentiation between KGI and libggi;
KGI is the small subset of what is absolutely necessary to get at the
hardware in a stable manner. libggi and friends provide a low-level
uniform interface to that kernel interface (or to X primitives, or to
SVGAlib, etc). libggi is designed to be crossplatform, and support as many
targets as possible. KGI is intended to be a minimalist interface to the
hardware.
> The protection provided by the kernel for access to registers and RAM is
> completely artificial, requiring the server to operate as root for
> access. Otherwise any user's program could screw up the chip timing and
> burn out the monitor.
That's what KGI is all about: it protects the hardware from the user, just
like any other kernel driver, instead of letting usermode apps (like X,
SVGAlib-based software, etc) beat on the hardware directly, and
potentially damage it.
Do you like the idea of apps hitting SCSI devices directly, instead of
having the kernel protect your drives from unauthorized (or authorized,
but poorly written) access?
> Since the X-Server is BIG, it operates entirely in user-mode. The
> kernel just lets it have access to the graphics chip registers and
> screen RAM. There is no security problem that an alternate interface
> would eliminate.
Each display driver attempts to ensure that access to that particular
hardware is safe. That's one of the main points behind doing this in the
kernel: there should be no way in which a userspace program should be able
to damage the video hardware, or leave the console in an unusable or
inconsistant state. Currently, because of multiple userspace schemes for
access to the graphics hardware, this is virtually impossible.
> Further, an alternate interface adds another layer
> of code between the real hardware and the User Interface.
I won't talk about benchmarks, since others have already posted about the
trivial performance differences using XF86 vs. XGGI (when comparing apples
to apples; accellerated vs. unaccellerated is a bogus argument...compare
an accellerated XF86 build against an equivilent accellerated KGI
driver, or unaccellerated versions of both).
> User's of graphics-capable machines won't accept a slower write to the
> screen for some alleged improvement in 'security'
Ask Dave Taylor why he's putting time into a GGI port for Golgotha, if you
need a developers' perspective. Ask Dave Kirsch why he's planning a GGI
target for Quake II. These are real developers, who write timing-sensitive
games, who apparently seem to like the idea of a stable interface to the
graphics hardware.
As far as the average user goes, see above about benchmarking; you're
-still- getting a layer of indirection with XF86's direct access schemes,
and that layer of indirection is the -only- way you can avoid problems
inherent in having multiple packages going after the hardware at the same
time. You need an arbiter, which is what KGI provides, along with the
security needed to keep those processes from melting your hardware.
(KGI isn't the only solution, but having a solution of this nature in the
kernel is the -only- way to ensure secure, stable hardware access. Hence
fbcon, for example. I didn't hear you scream about that addition. ;-)
> If you have physical access to a machine, there IS no security period.
> Use of the graphics capability of the machine requires physical access.
You're being extremely limited in vision. Consider that your peripherals
are located on your desktop, but the machine is actually wired up in
another location; a fairly trivial thing to do these days. You don't have
physical machine access in this case, but you -do- need a stable console.
> Were are talking about PERSONAL computers here, not some secure
> server locked away in a room.
-You're- talking about personal Win '95-alike machines here. I'm trying to
address a more global need for controlled video hardware access.
KGI attempts to address the problem of multiple tasks simultaneously
wanting video access, the problem that a userspace app needs to be root to
hit that hardware in the first place, and that currenly, a single
malfunction in a graphical application can render a console unusable.
Stability and security are what are currently lacking from the current
"display hardware interface", if you can call it that.
And, on those "PERSONAL computers", you can't just telnet back into the
machine from somewhere else to fix the screen when an out-of-control or
poorly designed app kills your only interface to it.
But hey, there's always the reset button.
-- -------------------. emarshal at logic.net .--------------------------------- Edward S. Marshall `-----------------------' http://www.logic.net/~emarshal/Spammers: Please email my blacklisting service at "spam@logic.net".
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu