Re: Hurd and the Alpha
> [Disclaimer: I can only *spell* Mach]
>
> Once upon a time there was some discussion on the list concerning the
> deficiencies of Mach, and the attractiveness of certain other microkernels.
> The consensus was something like:
> "Let's not waste time putting up another microkernel just
> yet. Let's get the Hurd running first."
>
> I guess that's probably sound advice -- if we're only talking about a
> single platform (x86). But it seems to me that if Greg wants an Alpha
> Hurd, and he has the wherewithal to undertake this, then it would be foolish
> to port Mach in light of our nascent desire to replace it.
>
> Comments? Corrections? Catcalls? Brickbats?
The work involved in porting the microkernel to a new platform is not
really very Mach-specific at all, and it is likely that any such work done
would provide source code that could be reused in a different microkernel
as well. If the approach is to port the OSKit and OSKit-Mach, that builds
in even more reuse potential from the start.
The basic important fact here is that the parts of a microkernel that deal
intimately with the hardware tend to be much the same for different
microkernels on the same hardware, and the parts that differ greatly
between different microkernels tend not to be parts that are innately
machine-dependent. Indeed, the hardware-related code in microkernels is
most often not deeply different from the hardware-related code in
monolithic kernels. What makes reuse difficult is that the code hardware
support code in monolithic kernels tends not to be very abstract or
modular; that is, it is not modular with respect to different basic
operating principles of a kernel, though it may be modular with respect to
different hardware platforms. The device driver pieces of monolithic
kernel code do tend to be more modular and use more abstract interfaces,
which is why Mach and OSKit do in fact reuse the device drivers from Linux.
Reply to: