Messages in this thread |  | | | Date | Sun, 29 Mar 1998 20:20:40 +0300 | | From | Rauli Ruohonen <> | | Subject | Re: Calm on the GGI waters.. |
| |
[Disclaimer: I'm not a kernel- nor a GGI-expert, I've only followed almost all the battles and read the GGI mailing list / docs a lot. The terminology I use here may differ from the terminology used by others, but it should be quite easy to understand what I'm saying..]
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
|  |