Re: Porting KGI to the HURD
Hello,
Marcus Brinkmann wrote:
> On Thu, Sep 30, 1999 at 09:19:48PM +0200, Steffen Seeger wrote:
> > My name is Steffen Seeger and I am new to this list.
>
> Hello Steffen,
>
> it's great that you find your way over here!
>
> > Brent Fulgram (I hope I spelled the name right) posted a message on the
> > GGI development list about people working on the HURD OS investigating
> > possibilites to port the KGI framework to HURD and looking for support
> > regarding the technical details of it.
>
> Yes. Let me summarize the current situation. We are using the Hurd servers
> on top of the GNU Mach microkernel. The Hurd is a multi-server OS, and thus
> quite different from the usual single-server or monolithic kernel OS you
> can find around every corner.
>
> The Mach has a simple built in console, and some simple built in mouse
> drivers. In this regard, the mach is not very different to the Linux kernel,
> for example (except that the Mach console is much more primitive).
So, in general drivers contained in Mach do the actual device access, while
the servers provide the application interface, right?
> [...snip...] But this situation is contrary to the design goal of the Hurd.
>
> To fix this, we want to have the console code outside the (micro)kernel.
This is preferrable, yes. However, there is one point that makes this a bit
problematic. (See also the KGI white paper draft below.) You have to provide
diagnostic messages during boot, which is why (text) output should be available
as early as possible.
> Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> started a simple colortext console
> server that fits better in the Hurd design. It writes directly into the
> video memory by memory mapping and will receive the scan codes from the
> keyboard by event mode of the mach keyboard driver. I hope that this server
> will be completed and gives us a small implementation of a console server
> for the Hurd soon, and maybe serves as an entry point for further efforts
> in this direction.
>
> This is where KGI comes in. It sounds as if KGI could provide a full
> featured terminal server (multihead/multiinput, virtualization of mouse,
> hooks for libggi library, hence providing a svgalib emulation layer and a X
> server, I am partly guessing here, please correct me if I am wrong).
One point after the other:
Terminal server with multihead/multiinput:
Yes, KGI was designed from the ground up to do that. On Linux,
this feature is realized by three essential parts:
- exactly one driver per hardware device.
- a central resource management system.
(resource == input and display devices)
- external mappers (I guess 'servers' is the
proper Hurd terminology) that provide applications
access to the devices.
By heart I would put the drivers inside the Mach kernel, while
the mappers could be servers; I am not sure about the resource
manager, but as the drivers have to rely on it, I would
tend to say 'into Mach'.
> It also looks as if KGI could be hooked in the Hurd design rather
> flawlessly, considering that it had to be developed as an independent
> project from the Linux main stream kernel right from the beginning.
Well, we wanted to create OS independent graphics drivers. I young and dumb
and didn't know what a mess I was starting to fiddle with... :-))
> I think the first step is for either of us to get a picture of the other
> projects field of operation, so we have a better picture of where the areas
> of contact exactly are.
I have made some articles available at
http://www.tu-chemnitz.de/~sse/ggi/KGI-white-paper.txt
http://www.tu-chemnitz.de/~sse/ggi/KGI-display-driver-overview.txt
The first gives an overview about the basic concepts behind KGI,
while the second gives more details of the drivers.
These have been written when presenting KGI to the UDI group. We are very
interested in getting KGI using the UDI environment, as it takes a lot of
portability burden from KGI. I hope this works out. [I am aware of the
political issues involved, but I tend to be pragmatic here. UDI solves
a lot of problems involved with writing portable drivers, so from a
technical standpoint, I have no reason to reject the good work they've
done.]
Steffen
----------------- e-mail: seeger@physik.tu-chemnitz.de -----------------
------------- The GGI Project: http://www.ggi-project.org -------------
Reply to: