[Top][All Lists]

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

Re: L4Mach or Refactor Hurd Servers?

From: Farid Hajji
Subject: Re: L4Mach or Refactor Hurd Servers?
Date: Sun, 11 Nov 2001 03:15:48 +0100 (CET)

> Apologies for the lack of information. My goal is to build a Hurd system that
> can run using an L4 microkernel. I see two basic options for doing this:
> 1) Create a /boot/gnumach.gz that uses L4. No changes to the Hurd code.
It would be nice, if it were possible. However, the Mach/L3 work mentioned
earlier showed that there is a lot of trouble implementing the whole Mach
functionality as an L4 server. This seems much more difficult than L4Linux,
but you'll have to ask Michael or Sven if they still see it that way and
also why they came to this conclusion. Please Cc: l4-hurd in this case ;)

> 2) Supplant /boot/gnumach.gz with an L4 microkernel and rework the Hurd
> libraries to use L4 features where they currently use gnumachs'.
This would be too much work, and the split between Hurd/Mach and Hurd/L4
would become too wide. Parts of the Hurd should be IMHO rewritten in such
a way to avoid things specific to Mach-IPC, putting most of the rest into
the realm of a stub generator. therefore:

3) Supplant /boot/gnumach.gz with /boot/l4ka and provide a vk-l4 environment
that aims to implement generic mach stuff (vm, devices, simple IPC); at the
same time, modifying the Hurd's sources to rely more upon an interchangeable
RPC stub generator, dropping Mach-specific IPC stuff as discussed earlier.

> I understand what would be required for (1) better, so initially it seems
> attractive. However, as you pointed out, I don't see how useful that would be 
> as
> a resulting system. I think I will work on (2) and see where I can get to.
There are actually two fronts on which we need to work:

  1.) From the bottom up, i.e. by writing the VK/L4 environment that we
      are currently talking about: UVM-Pager, L4Env Device-Framework,
      Flick or other IDL stub generator.

  2.) From the top down, i.e. migrating from MiG to IDL-Flick/Mach3,
      removing Mach-specific IPC calls etc... [implementing as much
      as possible from our "wish-list"].

1. would be done by people willing to play with L4 and low-level system
programming in general, in coooperation with L4 hackers at Dresden,
Karlsruhe and at UNSW among others. 2. would most likely be done by
Hurd/Mach hackers [if we can convice them], in close cooperation with us.

Both parts can be started immediately and can proceed in parallel until
1) a basic VK/L4 environment stands, so that we can boot from a disk
   [device framework must be ready], start up a pager [vm must be ready]
   and load some initial boot program [that would later load ext2fs
   and the rest of the Hurd]
2) the Hurd can be compiled w/o MIG, using only flick [or any other
   portable IDL-stub generator that can produce both Mach and L4 stubs],
   the glibc sysdeps are adapted to release the Mach dependencies somewhat
   [most of Mach ain't present in L4 and will have to be redirected to
    our VK/L4 libraries anyway], VM calls are being exclusively routed
   through vm_*() calls (no pager tricks), [so that we can plug in our
   own pager(-library)]...
At that point, we'll need to closely work together to adapt both the
Hurd sources and the VK/L4 environment to get a fully functional system
up and running.

> -- Ian


Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | farid.hajji@ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]