Mach independence
The HURD claims to be a group of servers which is currently running
on the Mach microkernel but which could use another microkernel in
the future.
Honestly
1) Its source is cluttered up with Mach-specific data
structures/syscalls/library calls.
2) Even ordinary HURD applications that don't rely on the POSIX layer
use Mach stuff.
It is true that you can use POSIX (and pthreads in future) and stay
portable but you can't fully utilize HURD features this way. And for
all IPC servers (including HURD itself) this is not sufficient at
all.
I am interested if you really want HURD to be independent HIRD of
Daemons or you are content with those mighty daemons being rather
herd grazed by the Mach herder forever ;-) At this time it is not
possible to port HURD to another microkernel without splitting its
code base and this makes any porting efforts meaningless. L4-HURD
seems to be dead for now because of this.
HURD adopted many concepts from Mach. This should not be a problem
(lets hope) but it must not depend on exact realization of these
concepts (i.e. Mach API). HURD needs a thin layer (abstract wrapper)
over Mach (this layer would be substantially thicker for other
microkernels of course). This wrapper would only cover the portion of
Mach services that HURD often uses.
It could be just some sort of Mach emulation layer (with "neutral"
function names - e.g. no "mach_xxx_yyy" but "mk_xxx_yyy") to some
degree. This would be easy to implement for Mach and ports to other
microkernels would become possible.
Some Mach functions doesn't have to be included in this abstraction
layer because they are already covered by POSIX or pthreads. And
there is no big need for a full-featured microkernel abstraction
library and for forbidding direct microkernel access - small part of
application/server code can and will remain dependent (even just to
exploit specific microkernel abilities). But it should not happen
very often that you need to access microkernel functions directly
from ordinary applications/servers.
Microkernel-dependent code should be strictly separated from the rest
so you know what is the subject of porting effort. All
servers/libraries should place its bits of dependent code into
special subdirectory (e.g. "trivfs/arch/mach") similar to Linux
"arch" directory.
What are your thoughts on this subject ?
I think this issue should be solved before people start to write
HURD-specific (non-POSIX) software. I am not able to do it myself as
I am no HURD/Mach/L4/whatever expert. I would like to do some coding
for HURD, no design. I have just begun studying the HURD so I hope i
didn't blather too much nonsense and sorry for my broken eNgluSh ;-)
______________________________________________________________________
Jak poslat rukou psaný text na mail? Přece faxem Panasonic!
http://www.panasonic.cz/redirect.html
Reply to: