Re: Porting KGI to the HURD
On Mon, Oct 04, 1999 at 10:39:04AM +0200, Steffen Seeger wrote:
>
> So, in general drivers contained in Mach do the actual device access, while
> the servers provide the application interface, right?
Well, yes. The main ABI is of course the GNU C library, which communicates
directly with Mach and the Hurd servers. Some applications may choose to
communicate with Mach directly, or with the Hurd servers, but most
aplications only use the POSIX interface exposed by glibc.
The C library for the Hurd has much more code than for Linux. It does,
together with the Hurd servers, signal handling, process managment
(including process groups etc).
> > [...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.
Well, this is only because the Linux kernel is so verbose. :)
Seriously, the GNU Mach kernel itself does only print one or two lines
before start up (Name and Version number).
The Linux device drivers that are currently in GNU Mach print out there
usual diagnostic info. The same goes for the Mach device drivers (most are
deactivated by now).
So, in a real microkernel model, the kernel would be so small that no
diagnostics is printed, so you don't need a console subsystem at that stage
(but the console would be started up very early).
Currently, we have to deal with a mixture, which complicates things a bit.
Beside the actual console logging (which could be solved using the kernel
message device and klogd), I see two more problems: The Mach kernel
debugger needs a console device. The Hurd bootstrap tasks open a mach device
stream to the "console" device. So it seems we indeed have the need for a
console device in GNU Mach.
But I wouldn't say that this couldn't be fixed. I could imagine that we
leave the dumb console device in GNU Mach active for this purpose. I could
imagine that we replace it with a minimal console that can be controlled
by the KGI (which resides completely outside the kernel). I can imagine
moving all device drivers outside GNU Mach (using the OSToolKit?), which
solves this problem in a nice way (but has other problems).
Note that I can't offer solutions, I don't know enough about the issues
involved. But I hope I can point out some possible alternatives and add
another point of view in this discussion.
> One point after the other:
Of course.
> 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'.
Mmh. I already mailed to the GGI list, that if parts of KGI start in Mach,
along side with the other linux drivers, this would not be a big problem.
But still I think we should at least try to identify those parts and
minimize them as much as possible. Also, in the long run, we will eventually
switch to another microkernel, possibly one with hardware devices in
userland, so at some point it will be more natural to put KGI completely
in userspace.
> > 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.
Thanks, I will read them after fetching something to eat :)
I hope that many people on this list will read them and comment on it, too.
> These have been written when presenting KGI to the UDI group.
Not everyone on this list probably knows what/who UDI is. Can you give us a
reference/link and a very short summary of their goal from your point of view?
> 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.]
I think you are referring to the possibility (and easyness) of providing and
using binary only drivers.
Well, it seems that KGI would in this case build a bridge between the Hurd
and binary-only modules. If this is the price we have to pay, we might need
to pay another price, too which relates to the accpetance of KGI by the FSF.
Only a careful examination of all licenses involved will be able to answer
this[1], so I would like to postpone this part of the discussion until I know
the license and functionality of KGI and UDI components [2]. BTW, the KGI
snapshot tar file does not contain a license at all!
Thanks,
Marcus
[1] Note that the Hurd libraries, to which KGI will have to link, are
licensed under the GPL, not LGPL.
[2] Important in this analysis will be that the LGPL can also automagically
transform to the GPL if required license-wise.
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
Marcus.Brinkmann@ruhr-uni-bochum.de, marcus@gnu.org PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ brinkmd@debian.org
Reply to: