RE: Some questions
> 1) Am I right if I think that a microkernel has nothing to do
> with small size? Although Mach and the servers are not
> _really_ big (like NT), they seem to be bigger than Linux
> (and modules) for the first sight. How will this (and the
> advantage, that the whole system is in several parts) affect
> its applicability in - say - embedded devices?
>
The current implementation of GNUMach has just about every driver
included. This is analogous to a Linux kernel with no modules
and every driver built in (much like the default Kernels found
in install sets).
If you compile your own GNUmach for your system, you will most
likely see a much smaller size. Furthermore, most drivers are
based on the Linux device drivers, and have not been abstracted
out of the microkernel as the design goal dictates. So, you
are looking at an incomplete implementation.
> 2) You say it is good to put the servers in user space. Is it
> the same as user space vs. kernel space?
Yes
> If I understand well, the separation provides memory
> protection as well (crashes, garbage in memory).
Yes. And user-defined drivers that could be different
for different users on the same system.
> If yes, don't you loose something with not separating?
>
I'm not sure I understand this question.
> 3) If there is no centralization in the kernel, how can a
> developer make such a server that is transparently usable
> for those softwares, that are not explicitly designed to
> support the new features. In other words: if there is nothing like
> the kernel release (and syncing) in Linux, what makes the
> _whole_ thing coherent?
>
The C runtime library provides much of the standard Kernel
features in Linux. These are all system calls (at least what
you are referring to). The program generally does not care
if he is making a call that exercises some Kernel code (as in
Linux) or activates functionality in a translator or external
driver (as in the Hurd). The result is the same. Still,
sometimes special handling is needed to do things on the Hurd.
This is to be expected since the two systems have different
architectures. It is actually amazing to me how easy it is
to get things running on the Hurd based on standard Unix
source code.
> 4) Is it possible to develop a translator that turns the ext2
> filesystem to something like the one of the "Be"? If I have seen it well,
> it can record auxiliary data for a file regarding to the author, the
topic,
> the project it is a part of.
>
I think you may have this backwards. It would be possible to
create a translator for the Be file system standard so it
could be used on the Hurd. It is generally not possible to add
new features to an existing file system, simply because the
necessary framework to generate those features (such as allocated
areas in the file system structure for storing data, etc.) are
not present.
> 5) Can something like a "database filesystem" created?
> Something than can produce views of the underlying files
> according to properties (like above). Like a directory with all
> my data files, one with all my documents, one with all my
> programs, and just another with data per preject. Doing this
> with symlinks is a nightmare (updating).
>
I'm going to punt this to Roland or someone knowledgable. Still,
it seems possible. I mean, we have an ftp-based file system, so
anything goes in my book.
> 6) Will the Hurd be ready (to the extent like Linux is now)
> when Debian releases 2.2?
No. We freeze potato (Debian 2.2) this weekend. It will release
in a month or so. There are still issues with the Hurd needing
to be resolved. Still, the Hurd is very usable for many things
right now.
> 7) I am Hungarian and miss the keyboard layout very much. Is
> it available? If not, can I make one? Please let me know...
>
I believe that someone has started support for keymaps. Unfortunately,
our console code is still rather simple.
-Brent
Reply to: