Lourens Veen wrote:
Finally, as a technical note, I think we're talking too low a level
here. I would like to see a discussion from a more philosophical point
of view first:
What is the job of the kernel with respect to graphics?
As someone else mentioned, there are two interpretations of "kernel",
the "micro-kernel" or the "micro-kernel" + all driver modules. I should
also point out, that in this case, the linux kernel minus all drivers is
what I would consider the micro-kernel. I will start in the realm of
the micro-kernel.
The micro-kernel has zero to do with graphics. It provides secure
brokered access to memory regions and (on processors that support it)
i/o regions. It provides raw access to the the device: a safe and sane
way to write to the memory space and/or register space of the device.
It also provides the hook for interrupt call-backs. How the hooks and
call backs are handled may depend on the system architecture, but
minimally it should provide a way for a higher level block of code to
register itself to be called when a particular interrupt is generated.
That's it, nothing else.
What does the kernel need itself in terms of graphics/user interaction?
The micro kernel needs very little, generally just some basic text
output. Anything else can be handled at a high level in the system. In
systems where the boot screen is graphical, like Solaris, Irix, or newer
Linux system, this is still handled at a higher level of the system.
Once you get to this part, you can have a basic driver available that is
not technically part of the micro-kernel, like the Linux fb driver.
What abstraction should the kernel offer to userspace?
The micro-kernel: none. User space abstraction is the job of the driver
that understands the hardware and how to communicate with it through the
basic interface of the micro kernel. It is at this level that Richards
arguments, in my opinion, apply. The driver should present an ABI to
userspace and the kernel. It is this ABI that should be standard. This
falls somewhere slightly below DirectX or OpenGL as it should include
the less abstract tasks of switching video modes, letting a userspace
application set an interrupt call-back, etc, as well as methods to
actually display data on the card. Any functionality provided by this
ABI that the card does not directly support should be emulated in
software if possible or return meaningful information if not. You could
make the argument that the display part of the ABI is seperate from the
operational piece.
The larger kernel (micro-kernel plus drivers) must have access to this
ABI as it continues the process of initializing the system. I can
certainly make the argument that the kernel doesn't need full 3d
graphics capability to do boot time display, really all it needs is
framebuffer level stuff. By the time the boot process is really under
way (i.e. we are in the init process) the loadable module should be
available. I would really want to avoid statically linking any part of
the display ABI into the kernel itself.
Sound familiar? It's not too far off from the current Linux driver
structure at the architectural level, though the demarcation between
kernel and driver should be more formal than it is. The problem here is
not one of programming, it's one of standardization of a single ABI.
This is where Microsoft and Apple have a serious advantage. The can
mandate a standard interface: i.e. DirectX.
Patrick M
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
