Uh. This is kinda *long* 8-) I hope that people read this, though,
since it probably clears some things up. Or maybe it totally messes
them, after all, I might be wrong *myself*! Well, the GGI guys will
correct me, if I am.
In linux-kernel Linus Torvalds wrote:
>Think of it as a very basic kind of driver, but a driver that makes no
>policy. The kernel only really guarantees that it can write characters on
>the screen.
>
>In contrast, the GGI kind of interface implies a lot _more_ in the way of
>support. And by implying that, it ties my hands: I am no longer free to do
>what I think is right, because I have to abide by the interface.
AFAIK, this is wrong. The basic idea of the GGI is this:
The kernel side has to export the graphics functionality in the best way it
can, and the user space code should adapt to that. The kernel interface of
two different cards don't have to resemble each other at all! There are
no restrictions. If the best way to export graphics functionality is to
do everything in the user space, then there is no need for a kernel driver.
This is currently implemented in the standard Linux kernel, but nothing
else.
A "GGI driver" means always two drivers: A kernel driver and a user-space
driver. If the kernel driver doesn't do something, the user-space driver
has to do it and the other way around. The user space driver is not your
concern unless you want to develop libggi, X, or whatever. You are
interested in the kernel side of things. If the kernel interface changes,
the user-space driver should be modified so that programs work even
without a recompilation. Thus the hard abstraction work is transferred to
the user space. There is no "one, correct user-space driver", and in
fact, no "one, correct kernel-space driver". Users have choice! There is
no well-defined interface between the user space and the kernel space,
the well-defined interface is between the user-space driver and the
user-space program. The user-space driver may be libggi, svgalib, XFree86,
or whatever. The applications programmer chooses the user-space driver
(s)he wants to use.
Let's assume that there exists a graphics card called "Bogus" that needs
a driver. The current scheme works this way: The kernel driver is a null
driver, and the user-space driver is in your case the XFree86 server.
This doesn't work for everyone, since some people don't trust in XFree
and want it to be non-suid, or they want to have an svgalib equivalent
for games (and don't want to have setuid-root games!). So, these people
write a kernel driver (a module) to export the capabilities of the card
to the user space in a safe way.
Let's now make another assumption: The kernel interface exported by the
Bogus-driver is completely different from *any* other interface,
including any of the interfaces of the other card drivers. Of course, the
user space driver, XFree86, is now unable to work with this interface, so
the guys go and patch it to support the new, fancy kernel driver. The
applications don't need to be changed, and users can now choose between
the old driver combination and the new one. Neither one is shoved down
anyone's throat.
Now, this way of implementing the card drivers is pretty ugly! Every
kernel driver has to have its own kernel/user communication support, and
it will cause terrible amount of duplicated code! So, the GGI provides
the drivers "standard functionality", such as Ping-Pong buffers,
automatic MMU-based plane-switching, some standard ioctls, etc. The
kernel driver doesn't *have to* use these, though! They are there just for
convenience and to reduce the code bloat. The EvStack also might belong
to this category.. I'm not certain, since the GGI people seem to want
to separate it from the GGI in the way like memory management is
separated: The GGI uses it, but still it's not a GGI feature.
This "standard functionality" is what the GGI kernel patch contains. It
doesn't contain the kernel drivers nor the user-space drivers. The
kernel drivers are modules. One thing that has made the debates very
messy is the fact that the GGI also began "fixing" other console-related
stuff like input, which has nothing to do with the graphics drivers.
IMHO, it's still appropriate, since a main point in the existence of
the GGI is games, and games need a decent input support..
The GGI user-space library is a "user-space driver" that interfaces the
"GGI applications" to the kernel drivers, and it's designed to be very
portable, fast, and flexible. The GGI guys have ported X to use the
GGI library, and also have an "X target" so that all GGI programs can
be run in an X window. This library is a whole new can of worms, and
can be debated later (it even isn't on-topic for linux-kernel list!).
The fact is, that the GGI user-space library is NOT REQUIRED to use
the kernel drivers. If no driver is insmoded, you can use vanilla
XFree, which provides roughly the same functionality as the GGI lib.
Also, if I wanted to implement a competitor, say "libGURGLE", I
could do so. It's a hell of a big job but I *could* do so! I could
also implement XFreeTwo, if I wanted, but that would be at least as
big a job.. :) The majority of programmers would just use GGI library
or libX11.
Shortly, the model the GGI proposes is not that different from the one
used currently, and it in no way restricts the modification of the
Linux kernel. Only restriction there is is between the user-space
drivers and the applications, and this restriction exists even now (if
I change the X protocol completely, will the X apps work without
modification?).
>As a result, I kick back _very_ strongly because I don't see any
>"obviously correct" interface. I'd be happy either with something very
>generic (basic DMA and interrupt interfaces to XFree86, for example), or
>something very specific (some very limited subset of XAA for example: only
>the bare necessities to make XAA easier to do). But anything else is not
>"obvious" any more.
You can think of it as many "very specific" interfaces: Each kernel card
driver has its own very specific interface, and the user-space library/
server/whatever makes the interface to all the drivers look the same.
This way the very specific kernel/user interfaces can be made as fast as
possible without having to worry about compatibility with a certain
protocol.
The user (or the applications programmer) doesn't ever need to know about
the kernel/user interface, so it may be changed in any way as long as
both kernel and the user drivers are changed so that they are compatible
with each other..
NOTE! Although this post is quite long, it still simplifies the design of
the GGI significantly. In addition, I'm not arguing now about the technical
details of why a "Ping-Pong buffer" support is needed for the kernel drivers,
or anything else, since those issues are irrelevant to the general concept.
(and the other reason is that I don't know enough about Ping-Pong buffers..)
-- Who is General Failure and why is he reading my hard disk? -- Felix von Leitner- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu