Re: configuration

[OKUJI Yoshinori]

From: Farid Hajji <address@hidden>
Subject: Re: configuration
Date: Sat, 4 Nov 2000 04:27:35 +0100

> I don't understand how GCC depends on Mach. Please enlighten me.

  As I said, see the "specs" file. I don't think we need to use
another version of linker scripts (or executable formats), so all we
must consider is specs.

> I choose the name libvk for the following (trivial) reasons:
>   1. I have no idea what libmom really does (do you know under which
>      CVS tag libmom can be downloaded? I'd like to have a look at what
>      was already there)

  It was not more than just an idea. So Thomas removed it from the CVS
tree. If you want to see what it was, you can download it by
specifying a date tag. Sorry, I don't remember when he removed it. But
if you browse the cvsweb interface, you will be able to get it
efficiently.

>   2. I wanted to avoid name clashes with something I don't know anything
>      about.

  Good point, but libmom doesn't exist any longer. So you can call
libvk "a new version of libmom". :-)

>   3. libvk should also be available on guest-OSes. Was libmom intended
>      to do that?

  Of course. MOM is the acronym of "Microkernel Object Model". The aim
was to hide microkernel-specific models in a library which would
provide generic objects and their interfaces.

>   4. libvk functions should be defined inline as far as possible for
>      max. speed. Quid libmom?

  I don't think Thomas did consider that. But inline functions don't
necessarily perform better than non-inline functions, because those
increase the size of code. As you may know, there are several real
examples for that. For example: RISC is not faster than CISC, and L4
doesn't define two system calls for short-message IPC and long-message
IPC. That's because more code means less cache hits. Inline functions
are better, only if they don't increase the size of code (very much)
and you really need to speed up code that uses them.

Okuji