> > I regard such as overly simplistic and therefore
> > strawmen.
>
> The situation *is* really quite simple. Video drivers belong in
> the kernel.
>
> Jon
>
> * end quote *
>
> I disagree with you here. But only partially. My understanding of KGI
> may be very flawed, but I will refer to my understanding of it here.
>
> The Kernel is not necessarily responsible to have drivers for every
> device in it. But, in a true OS desing such as Linux or Unix, its job
> is to arbitrate, control access to, and provide a consistent interface
> to all devices of same type.
To be specific, the job of the OS is not (necessarily) to "drive"
hardware in traditional sense (hook an API to it), but to multiplex access
to it. The ultimate expression of this philosophy is the 'exokernel' OS,
which does *nothing* but multiplex the hardware. Even more stuff is
outside the fixed kernel than in a microkernel.
The "consistent interface" part only goes as far as the hardware
itself has a consistent interface. Any time you impose the same interface
on different hardware, you end up either not being able to use some
functionality of one type of hardware because that functionality doesn't
fit into the API, or you end up needing to emulate some functionality of
another type of hardware to make sure every part of the API works.
> It is my understanding that KGI/GGI (together here, because I think it
> is both in this case) provides just the absolutely needed parts in the
> kernel to provide safety, security, and stability.
KGI is the kernel part, the video drivers and the video driver
framework they plug into. All the KGI drivers do is safely export the
hardware's feature set into userspace.
> The rest I believe
> is user space. (No, I am not educating you on a project you take more
> part in than myself... I take none, just try to stay up on
> design/technical issues of it.)
LibGGI is the userspace part. It is a set of dynamic libraries
that implement a set of grpahics-related APIs. "driver" libraries can be
dynamically dlopen()ed as needed to bridge the fixed APIs to the non-fixed
KGI driver capabilities for maximum optimization potential. LibGGI is
really just the dynamic library system with retargeting and doesn't do
much by itself. Other LibGGI-using extension libraries are built on top
of LibGGI's base functions and provide more specialized tools:
* LibGGI2D, which as you might expect from the name does 2D graphics
(lines, circles, bezier curves, ellipses, etc) and is roughly analogous to
SVGALib's LibGL.
* LibGWT, which is a 'Viewports' primitive window/region handling
system. More complex windowing systems with menus, dialogs, mouse
handling, etc can be built on top of it.
And more are planned, like LibGGI3D, LibMESA, LibGDK (for games),
etc. LibGGI can also 'retarget', which means that it can render to any
one of about 15 (currently) back ends: KGI, SVGALib, Glide, Terminfo,
monotext, AALib, Xlib, XFree86 DGA, VNC, and others. Targets for Win16
and Win32 GDI, Win32 DirectX, OpenGL, Macintosh, etc are on the TO-DO list
and the DirectX target is already underway.
> The argument: I think in the case of video that the kernel interface
> should be the absolutely smallest possible. I believe it was either
> Einstein or Edison that said, "Things should be made as simple as
> possible and no simpler."
We (GGI) agree completely.
> Put enough (Very small amount) of the code to
> allow mode changing, register access, console stuff, etc, in the kernel
> and leave the rest for user space libs etc to twiddle through some
> interface (syscalls?).
ioctls, probably. The sticky issue with all of this is system
stability. PC video hardware is by and large crap, and it just isn't safe
to allow direct register access from usersapce in many cases. You have to
wrap the hardware functions in ioctls so the driver can ensure that no
misprogramming takes place. Unfortunately, which parts of the hardware
functionality are safe to allow direct access to and which are not varies
quite widely from video card to video card. So, the interface to
userspace will also vary quite widely from KGI driver to KGI driver.
The icotls thing costs you some speed and some flexibility. It is
possible to exposte the hardware directly to userspace by mmap()ing the
MMIO registers of the card. If a user wants to sacrifice some stability
for speed, like some gamers might want to do, that can be done and the
LibGGI-KGI interface code will be able to handle this different method off
communication. But the default assumptions is that people are willing to
trade off a bit of speed in exchange for rock-solid stability.
> Now, just like SCSI cards, this may mean what is in the kernel changes
> depending on how much support (generic VGA) or the type of card
> (Permedia 2) you want to support, but the interface to programs should
> remain the same.
*Some* of the interface will remain the same. In KGI (and in
fbcon), the concepts of a linear framebuffer, horizontal and vertical
pixel grids, and pixel depth are assumed and a fixed function API is built
around those concepts. Not much else is, though. When you get beyond
basic linear framebuffering, card features diverge rapidly. You simply
cannot shoehorn all of that into any kind of fixed API. So we use ioctls,
which can encapsulate pretty much any kind of function you can think of.
> I will admit, when I mispoke and frustrated GGI people, Linux, and I
> believe Alan and Dave as well when this debate last raged (8 mos ago), I
> promised myself I wouldn't get involved in this debate ever again. I
> just needed to speak my small part, especially the quote from whoever it
> was that said it (I know it was one of the two). I think it is some
> good words to live by in any software development project: be it kernel;
> monolithic or microkernel, database, office suite, whatever.
Right. But the "and no simpler" part is what is important, as you
said.
> Trever Adams
> highlander@teleteam.net
>
> P.S. Please do not CC anyone directly with any text from my message
> unless they responded directly to it in the first place. I do not like
> flame wars and do not want to help keep this one going.
It would be *REAL* nice if vger could stick a Reply-to:
linux-kernel@vger-rutgers.edu onto every linux-kernel post. It would stop
this problem of building up a huge cc: list. The GGI list does this and
it is a wonderful feature.
Jon
--- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
- 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.altern.org/andrebalsa/doc/lkml-faq.html