[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Some Hurd/GGI Q&A



On Fri, Oct 01, 1999 at 08:40:28AM -0700, Brent Fulgham wrote:
> Rodolphe Ortalo <Rodolphe.Ortalo@cert.fr>
> =============================
> > The main questions we are trying to resolve are:
> >
> > 1.  How to best break KGI/GGI into a kernel/user codebase.  Most
> > processes (such as the ext2 filesystem) live in "user" space.  Only
> > very specific things go in the microkernel -- those things that
> > have to deal directly with the hardware.
> 
> Then, just reuse the KGI part for kernel and LibGGI part for
> userspace.
> 
> BTW, I am serious, and I know the specific habits of microkernel
> context. KGI really is the minimal part that is obliged to fiddle with
> the hadrware. Apart from the drivers, a more generic part of KGI
> provides a context for one driver programming (or more precisely,
> programmer ;-) but in the end KGI is the graphic cards driver so
> needs to access the hardware.

I would like to point out one minor (or gigantuan, depending on your
perspective) detail: KGI isn't just a graphics driver interface. It's an
entire console and I/O subsystem, including its own hacks to character
devices/etc to allow things like true multihead. When Linus finishes his
implementation of USB, KGI will be phat (so long as the generic vga console
in KGI 0.9 is working correctly of course. Imagine a box with three USB
keyboards, three PCI graphics adaptors, three sets of USB headphones, three
USB mice, etc.... each with 10 VC's ;). This just may be the expanded market
more powerful systems like merced and alpha have needed for such a long time.

Anyway, coming back from my tangent. It seems to me that only a very small
portion of KGI should actually go into mach.

-- 
..Aaron Van Couwenberghe... ..avancouw@calpoly.edu.. ..aaronv@debian.org..
	Berlin:			http://www.berlin-consortium.org
	Debian GNU/Linux:	http://www.debian.org


Reply to: