[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Mach, a but choise ?



On Sat, 09 Dec 2000 22:40:01 +0100, the world broke into rejoicing as
Farid Hajji <farid.hajji@ob.kamp.net>  said:
> > First of all, thank you for helping this newbie, your explanation have been
> > very clear to me, there are still two questions I would like to ask about
> > what you say of Mach offering more services than The Hurd really needs.
>
> There are many Mach versions available out there, gnumach being just one
> of them. I don't know of any Mach standard that all Mach implementations
> are required to implement. It _seems_ that the most "canonical" recent
> Mach is osfmk (see: http://www.mklinux.org/). There are variants of Mach
> that do real-time (like rtmach from keio/rtt) and yet other Mach variants
> provide NORMA-2 (unfortunately not released to the public by the OSF).
> 
> What kind of features are missing (or not working) from Gnumach?
>   - norma/xmm
>   - support for multiprocessors (rudimentary present, but not working (?))
>   - real-time extensions
>   - ledgers

At this point, a notable "missing thing" is...
  - Working support for architectures other than IA-32

> > first: is all this extra-functionality still present in the GNU version of
> > Mach the Hurd currently uses or has it been removed for the sake of resourc
e
> > consumption ?
> AFAIK, the Hurd uses/requires quite a lot of Mach semantics/functionality.
> Fortunately, the Hurd doesn't rely on _specific_ features of gnumach, that
> are not available elsewhere. I suspect that the Hurd could run on top
> of other Mach(s) as well [say: on a NeXT workstion and other Mach platforms].

I can't agree with this.  NeXT and OSF/1 were both systems based on 
the _early_ Mach model; it was _not_ a microkernel at the time, but
rather an attempt at a "new standard" for Unix kernel functionality.
They doubtless share some of the threading semantics, but the
"multiserverness" of Hurd would be problematic on a system with no
microkernel...

> Mach-functionality that is not needed by the Hurd is so small, that it
> wouldn't make sense to be removed from gnumach. There is not much to
> win to do so: The memory footprint won't be reduced enough like what is
> done in L4 and the system won't be faster either.

There are things to learn from L4, particularly in terms of the 
techniques needed to build efficient implementations.  The notion
that throwing in L4 will magically make Hurd smaller and faster seems
pretty wishful...

> > second: if it hasn't been removed, is it just because the complexity of the
> > whole microkernel doesn't allow it without compromising cleanliness or
> > stability?

> Well, it would be always possible to remove some features from
> gnumach, if someone had enough expertise, time and patience to do it.
> But I would strongly advocate against it: There are other systems
> (OS-Servers) that run on top of one version or more versions of
> Mach. Removing core functionality from gnumach would prevent those
> OS-Servers forever from running in gnumach (say: you couldn't run them
> inside the Hurd!).

> Consider one example: The Lites OS-Server is able to execute FreeBSD
> binaries that don't need to be recompiled. Lites runs on top of Utah's
> Mach4 (therefore most probably also on top of gnumach), rtmach and
> other Mach's. Now imagine that you're running the Hurd on gnumach,
> settrans FreeBSD partitions (with /hurd/ufs) somewhere and boot Lites
> by running a simple task. Now you could use the FreeBSD system directly
> inside of the Hurd without need for recompiling. You could even run
> the Hurd _and_ FreeBSD/Lites at the same time (using different VCs)...

Lites seems to have morphed into xMach... <http://xmach.org/>

I would think there to be considerable merit in there being some
convergence between Hurd and xMach on the microkernel side; if that
resulted in coexisting "personalities" that would be intereesting
indeed.
--
(concatenate 'string "cbbrowne" "@ntlug.org") <http://www.hex.net/~cbbrowne/>
"For be a man's intellectual superiority what it will, it can never
assume the practical, available supremacy over other men, without the
aid of some sort of external arts and entrenchments, always, in
themselves, more or less paltry and base.  This it is, that forever
keeps God's true princes of the Empire from the world's hustings; and
leaves the highest honors that this air can give, to those men who
become famous more through their infinite inferiority to the choice
hidden handful of the Divine Inert, than through their undoubted
superiority over the dead level of the mass." --Moby Dick, Ch 33



Reply to: