Hey everyone. I'm forwarding some comments from one of the other Hurd developers regarding implementing GGI: -----Original Message----- From: Marcus Brinkmann [mailto:[EMAIL PROTECTED]] Sent: Friday, October 01, 1999 8:01 AM To: Brent Fulgham Subject: ggi Hello Brent, can you forward this to the ggi list? Thanks, Marcus I am going to answer some questions of yours, thanks for your interest in the Hurd. I am not replying to Stefans mail here, I am looking forward to discuss all this in more detail on the Hurd lists, hope to see you there, too! Please CC' me, my email is [EMAIL PROTECTED] If postings to this list by non-subscribers are allowed, let me know the address, so I don't need to bother Brent with bouncing my mails to you. If you are interested in the Hurd, here are two links for you to get started: http://www.debian.org/ports/hurd http://www.gnu.org/software/hurd Thanks, Marcus Jay <[EMAIL PROTECTED]> ========================== BUT, from what I saw (and I must say again, I have NO experence with the Hurd yet) all you would need to do is make a daemon that talks directly to the hardware (about like X) in user space and leave the micro- kernel alone. In other words, make a "KGI server"-like daemon. This might sound horrable to Linux (and other non-MACH micro-kernel) users, but it seems to be the Hurd's way. I mean look at what "Hurd" means: Hird of UNIX-replaceing daemons. (Sorry, I can't remember what "Hird" meant) Does anybody have a daemon like this? ========================== Hello Jay, Your impression is correct, we want to move as much of the kernel out into user space. For example, the filesystem servers already run as normal tasks. The process registration is done in user space. The auth server handles authorization. The exec server starts up programs, etc. Currently, we use GNU Mach, but there are plans to switch to other microkernels, too, so every new development should take this into consideration. GNU Mach has a lot of hardwrae drivers build in (they come directly from Linux, we have glue code to make this possible). Although this is great for performance, it is contrary to the Hurd philosophy. I think with a stripped down hardware driver, which only provides a minimum of features, KGI can reside completely in user space. The other problem is that the Mach device interface is probably going to change, but this should be of little concern to you. A last note, Hird means Hurd of Interfaces Representing Depth :) BTW, what you call daemons is usually called a server on the Hurd, running on top of GNU Mach. (That's why Hurd is a multi-server OS as opposed to single servers like MacOS or NextStep, which also run on old Mach versions, and are more monolithic in design). ============================= ============================= Rodolphe Ortalo <[EMAIL PROTECTED]> ============================= > 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... ============================== Hello Rodolphe, I think this is not necessary. You can get direct access to the Video Memory, and a driver which will interface with the Mouse or Keyboard is already available, too. So you can just go and plug KGI in as another server in user space. This has other advantages, please see my reply to Jay above. Considering recent developments in "nano"kernels and other nice things, the minimal part of what you need in the kernel is really a tight definition, and the whole lot of KGI definitly does not belong there, ideally spoken. However, if we *start* with having KGI in GNU Mach and the rest in user space, I think that's a good way to get things rolling and get some experience. We can always make it "proper" at a later stage. However, it may be even easier to do it right directly from the beginning (I was porting the linux console to GNU Mach the last few days, and despite our working glue code there are many problems left.) =================================== -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNU http://www.gnu.org for public PGP Key [EMAIL PROTECTED] PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
