Unresolved Hacky Issues
This page lists a number of issues that still need to be worked out,
mostly with the build environment. This is not complete! Some bigger
issues---long term issues---aren't even here, and of course
no research issues are mentioned here.
Ideas and suggestions on these issues, or additions to this list, are welcome.
Kernel
kernel/chips:
I'm not quite sure what to do with the kernel/chips directory. The i386
port only uses chips/busses.c; for now I just put a copy of this file
into the i386 source tree and totally left the main chips directory out
of the build environment. This will have to be fixed somehow, obviously.
Perhaps since this directory essentially contains a general-purpose
"implementation repository" for real device drivers to use, it should be
placed into some kind of link library used when linking the kernel.
Perhaps the scsi directory should be in that library as well.
MIG stubs
Currently, everywhere MIG is used to produce client stubs for a .defs file,
all the client stubs are placed in a single .c file, instead of one .c file
for each client stub. This simplifies the build environment significantly,
but means that programs will get client stubs they don't need linked into them,
inflating program size. However, this problem may not really need to be fixed.
For one thing, in a more mature Mach-based system down the road, libmach will
probably always be used as a shared library, so all the client stubs will have
to be present anyway. Second, the GNU C library may make libmach obsolete,
because it contains essentially everything libmach does, and it already knows
how to deal with zillions of individual client stub files. Third, in the
new IPC system "on its way", client stubs are way smaller, and many are inlined,
so size is no longer much of an issue. Between these possible eventualities,
I'm hoping that at least one will come true and I'll be able to weasel out of
this job. :-)
User-level code:
User-level code and headers:
Another thing about the current system that I'm not sure I like is that the
public cthreads and bootstrap header files are mixed in with the public kernel
header files. For now this isn't too much of a problem, but it might be
desirable at some point to take all the optional user-level services such
as cthreads, libmach, the bootstrap program, and possibly other personality-
independent modules such as name servers and device drivers, and throw them
all into a separate package. (Maybe call it the Flock - "Flock of Low-level
OS-independent Common Kludges". :-) )
Hurd's cthreads and libmach:
The Hurd supplies a "slightly frobbed" version of libthreads
instead of the one supplied by the Mach distribution;
it would be nice if the "standard" libmach could be modified
so the Hurd could use it unchanged.
cthread_inline.awk:
Currently mach4-i386/libthreads/cthread_inline.awk is not used. I need to turn
those routines into real GCC inline functions and get rid of the awk script.
However, until then this problem should only affect performance.
NO_TYPE_CHECK_SRCS:
In libmach, I didn't include the NO_TYPE_CHECK_SRCS kludge, which would turn off
type checking for messages that are "supposed" to come only from the kernel,
which is trusted. This "feature" presumes that libmach knows what its clients are
using the Mach interfaces for, which totally violates the microkernel concept.
High-level software components can create their own presentations of the
standard interfaces with type checking disabled, if they want to. This change
shouldn't cause any compatibility problems, only performance problems on
servers that use libmach's default presentations on the assumption that they
will be "optimized" in this way.