Re: Future use of OSKit facilities in gnumach

[Roland McGrath]

> I see that GNU Mach links with a few OSKit libraries including
> -loskit_c.  However, it seems to require only a few functions from
> that library, and most (all?) of its OSKit dependencies exist for the
> device driver framework ("osenv").

That and booting, and for the unfinished SMP support, the SMP hardware drivers.
Also disk partition format reading, perhaps some miscellaneous facilities
I'm forgetting.  

When I wrote oskit-mach, I did it by ripping out pieces of the old native
i386 Mach code that were easy to replace with use of OSKit facilities.
Well, using the drivers was not "easy", but it was the main motivation for
the whole exercise and so was worth the substantial effort it took to adapt.

At the time, I generated in my head a catalog of all the things the OSKit's
facilities weren't doing for me, with an eye toward souping up the OSKit
interfaces and implementations to be more general.  For example, the whole
interrupt handling and software interrupt system.  It is pretty clumsy how
I have oskit hooks wedged into the old Mach interrupt system.  However, I
didn't want to just rip it out in favor the OSKit interfaces because that
would give up the BSD-style multiple interrupt priority levels and layers
of software interrupts; the OSKit irq and intr code only has "on" and
"off".

> I assume the reference is to liboskit_freebsd_c{,_r}.a.  Does that
> library figure at all in GNU Mach's future?

Not at all.  Those library interfaces are not the OSKit interfaces I am
using.  There are library interfaces, which are mostly intended to make
life easy for porting code written for user-mode POSIX systems.  Then there
are the COM module interfaces, which are a more separable, pluggable sort
of module system.  I only want to use those interfaces in the kernel.

>     gnumach/kern/assert.h:#include <oskit/c/assert.h>
>     gnumach/kern/bootstrap.c:#include <oskit/c/stdio.h>
>     gnumach/oskit/x86/main.c:#include <oskit/c/unistd.h>
>     gnumach/oskit/ds_osenv.c:#include <oskit/c/stdlib.h>
>     gnumach/oskit/ds_osenv.c:#include <oskit/c/termios.h>
>     gnumach/oskit/ds_routines.c:#include <oskit/c/stdlib.h>
>     gnumach/oskit/osenv_log.c:#include <oskit/c/stdio.h>

This stuff is really all using the "minimal" code.  This is just stuff for
booting and such, and things like _exit to reboot and printf for the
boot-time output on the minimal console.

> Certainly, I would be replacing x86/main.c, and maybe some of the
> others in gnumach/oskit/.  My question is, are there likely to be more
> files that use oskit/c stuff in the foreseeable future?

The use now is pretty minimal and if anything there will be less use rather
than more.

> I ask because I have a hope of turning GNU Mach into a GNU/Linux
> userspace application, and I am weighing which OSKit libraries and
> headers to try to include in the mix.

Well, good luck with that.  I am not much interested in it, and so you're
pretty much on your own.  However, making such attempts easier is what the
oskit approach to things is all about.  Every bit of Mach that I've ripped
out and made use some oskit COM interface is a bit that you can modularly
replace with your own implementation of that interface instead of the oskit
code I am using.  

The existing oskit-on-unix code ought to do you just fine for most of the
"hardware" support, i.e. replacing the boot path, the minimal console,
device driver, timer, etc. interfaces.  Really the only hard work you have
is the hard work of your plan, i.e. context switching and address spaces.

I am certainly receptive to making more parts of GNU Mach replaceable with
OSKit modules.  I think at the moment there aren't any that can be replaced
with existing OSKit modules without losing some worthwhile quality of the
i386 Mach code.  But you can certainly make some things conditional in the
source (#ifdef USE_OSKIT_INTERRUPTS or whatever).  Better than that, and
the longer-term way the oskitized kernel (if it survives at all) ought to
be, is to figure out how to improve the oskit interfaces and/or
implementations to do everything that's done now in Mach in a more modular
fashion.  Then you can replace those components with different ones
appropriate for a user-mode environment.

For your hack, you probably can get a lot done without going the most
modular oskity route.  Most of what you need to replace is in locore and
cswitch.