Brent Fulgham wrote:
> A few Hurd folks are making noises about porting KGI/GGI onto the Hurd.
> At one time a few of you were somewhat interested in this, but didn't
> make much progress.
>
> Can a kind, knowledgable soul join our "debian-hurd" mailing list and
> provide some technical support?
I guess Steffen Seeger will soon answer you... He's the one whose
advice is probably more appropriate of this point (no offence to
others...;-)
> 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.
LibGGI is the 'user' part.
Well, that said, maybe some adaptations could be done - but well...
> 2. How best to get FB support into the microkernel.
Don't you guess the answer you will have on this list< ;-)))
Anyway, it would really be wonderful if the Hurd could have
such a flexible mechanism for graphic cards. Frankly. Combined
with the rest of ukernel, it would be a powerful multimedia
platform. (Think to a camera writing directly to an ATM network
card output buffers, pictures going on the network, and then
out of another ATM card directly into the fb of a 4x4 wall display
system...;-)
Some people might recognize this system...
Rodolphe
