Re: Some Hurd and Mach programming questions
Date: Fri, 19 May 2000 13:24:13 +0200
From: Tomasz Wegrzanowski <maniek@beer.com>
Mach/MIG related :
1.
How accurate are 1987-1989 CMU Mach papers if GNU Mach is considered.
I'm not entirely sure. Some of these papers are probably discussing
things about Mach 2.5 and may be somewhat off-topic for GNU Mach.
The ones discussing Mach 3.0 are pretty relevant for GNU Mach. GNU
Mach, is based on Utah's Mach 4.0, but the differences between Mach
4.0 and Mach 3.0 are not very big. Mach 4.0 has some additional
interfaces (some of those were folded back into the final CMU MK84
release), and has for example a different boot sequence. But the
system calls and IPC interfaces are basically compatible.
2.
Are filesystem protocol and other basic client-to-server protocols
hard-coded in Mach or reside completely in Hurd ?
Most of it resides in the Hurd. But take a look for yourself. The
*.defs files in /include/mach/ are the Mach interfaces, those living
in /include/hurd are specific for the Hurd.
3.
How good is MIG ?
What special, non-obvious features are really in use if
compared to interface build on :
write (port, (int)sizeof(request), sizeof(int));
write (port, request, sizeof(request));
and
read (port, &size, sizeof (int))
request = malloc (size);
read (port, request, size);
I dont understand what you mean here.
4.
How good is MIG-generated code (size, speed);
I know that the OSF has made considerable changes in their MiG. So
the MiG in GNU Mach is probably somewhat sub-optimal.
5.
Does using lowest level Mach calls for IPC make any sense ?
This is done in several places in the Hurd. Grep for mach_msg. In
most cases this is done to circumvent limitations of MiG. It makes
only sense to do this in code that's really Mach-specific. Avoid it
if you want your code to be usable if the Hurd ever runs on a
different microkernel.
6.
How hard-wired is 1 GB max partition size.
I suppose this is due to lack of process' vm adress space
that needs to be used for mmaping the whole partition.
Is switching to diskspace-range-request-based store io
only way of having bigger partitions than processors' adress space ?
VM space is indeed the limitation. The architecture of libdiskfs
should be changed such that keeping track of the fs metadata no longer
requires mmapping the whole partition.
7.
What would be needed for Linux-based microkernel to replace Mach if
it had nice support of user-space filesystems and Hurd uids ?
The Hurd uses quite a number of Mach-specific features. The most
important ones missing from Linux are probably sane thread support and
an external paging interface. Implementation of user-space
filesystems and Hurd uids wouldn't be a problem. But I don't think
Linux will ever be a real microkernel, and I'm not sure if trying to
get the Hurd running on Linux would be such a good idea.
8.
Does it make any sense to move most device drivers (scsi/ide)
from Mach to user-space.
I suppose than PCI bus etc. would still need to be in kernel.
I suppose that you'll always need some basic support for a disk device
in the Mach kernel. Some other device drivers might be moved out to
Hurd related :
9.
Is this possible for fs translator to use its clients' data,
so we could for example implement something like /current/task/ with
env/ (as directory !), cwd, vmstat etc. files in it.
Sure. Although finding out what task is on the other end of the IPC
channel is somewhat difficult. But once you know that, your
translator can provide whatever data you want. Getting the
environment can be done with the help of the proc server.
10.
Is this possible for fs translator to use its' client's user's data
so we could for example implement something like /current/user/ with
home/, shell, mailbox, etc/ etc.
That's easier. Every translator already has the uids of the client
(for checking permissions).
Mark
Reply to: