bug-hurd
[Top][All Lists]
Advanced

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

Re: The Hurd: what is it?


From: Thomas Bushnell BSG
Subject: Re: The Hurd: what is it?
Date: Wed, 09 Nov 2005 20:09:51 -0800
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

"Alfred M\. Szmidt" <address@hidden> writes:

>    > Unix is a operating system developed by Bell labs.  That is quite
>    > concrete.
>
>    Huh?  Is Unix BSD, or is it System V?  Which?!  Or is it SCO?
>
> UNIX V6 for example, but you knew that...

It is as if you are not listening still.

Unix 32V (the Vax port of V7) was certainly Unix.  There were two
successor projects: BSD and System III.  It was meaningless at that
time to ask "which one is Unix"; Unix was both.  Indeed, it was
officially both, by decision of the federal courts, who found that BSD
had the right to continue to use the trademark.

But how does that change anything?  How does labelling this or that
change the world?  Suppose I declared, "The Mach-based codebase is the
Hurd, the L4 stuff is not the Hurd."  How would that have affected
reality?  It could still be that work on the L4 port is a better use
of people's time, and how would the labelling clarification have done
anything?

So I suspect that labelling is *not* the issue; that the real issue is
that you want me to declare "People should work on the Mach version
and give up on L4" or else to declare "People should work on the L4
port and abandon the Mach version." 

But hey, maybe I don't have a preference?  Maybe I don't know which
the most productive use of people's time is?  (And declaring that it's
my responsibility to know doesn't somehow beam the knowledge into my
head.)

It is not as if I had some seekrit knowledge or seekrit plan which I
was refusing to divulge.  You know, already, everything I know about
the issue.  There are no facts in my head about this, no plans about
this question whether solid or vague, nothing sitting waiting in the
wings.

Your tone has made this even harder; instead of asking questions, you
have berated me for not knowing the answer to a question that simply
*has no* answer.  I am not obliged to "bless" this or that code base;
if I choose to do so, it would be based on more knowledge and
information than I have right now.  I simply do not have the knowledge
or information upon which to make such a judgment; I suspect that
nobody does.

Generating that information and knowledge is something anyone could
do; it does not require any special privileges.  It requires people
investigating the details of L4, the details of Mach.  It requires
people coming up with technical arguments about the plusses and
minuses of both.  I am not in a position to declare that I know the
answer ahead of time; I do not have any intuition about the question
to offer except the following:

It is extremely unlikely that we want to use Mach forever.  Whether we
switch to L4 or something else, it is a near certainty that, at some
point, we will switch.  Mach simply has too many problems to be a
long-term solution.  It is therefore true that any work which factors
as much Mach-dependency out of the code-base would be productive.  It
is a guarantee that such work will help whatever the ultimate decision
is, whenever it is reached.

Many of the issues that the L4 port brought up are issues that affect
the Mach-based Hurd as well.  They are therefore issues that we should
seriously consider.  I do not have any particular opinions about what
should be considered and in what order, but I do agree with Marcus
that some redesign of some core interfaces may be in order (though, I
repeat, I do not have an opinion about *when* that should be done).
This redesign could be conveniently done piecemeal in most cases, and
could be done together with the above-mentioned refactoring.  Giving
the Hurd its own IDL, for example, not tied so strongly to Mach, would
be an excellent start.  Another task would be clarifying an exact list
of what is expected from a microkernel that the Hurd is to run on,
much in the way that GCC has its processor-specific and os-specific .h
files.  (Though, I expect, much much less complicated that what GCC
has.)

So there, if you want direction, that's what I can offer.

Thomas






reply via email to

[Prev in Thread] Current Thread [Next in Thread]