Date: Sun, 21 Jun 1998 17:45:09 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: phk@critter.freebsd.dk (Poul-Henning Kamp) Cc: hasty@rah.star-gate.com, current@FreeBSD.ORG, hackers@FreeBSD.ORG, dyson@iquest.net Subject: Re: Here is what I promised :-) Message-ID: <199806212245.RAA07936@dyson.iquest.net> In-Reply-To: <1737.898458035@critter.freebsd.dk> from Poul-Henning Kamp at "Jun 21, 98 09:40:35 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp said:
> In message <199806210022.RAA10841@rah.star-gate.com>, Amancio Hasty writes:
> >
> >Curious, are any of the core members interested in having John
> >come back --- in particular I am interested in hearing from
> >JKH and PKH
>
> I don't think John wants to come back, that is probably the most
> important thing.
>
That depends on the attitude of individuals in -core. My attitude
is to move forward on something that will do the same kind of thing
that I participated in on FreeBSD, and that is: given problems,
solve them. The existing FreeBSD kernel needs work, but as any
piece of software (except for the dinosaur-ware that seems to
have the Y2K problems :-)) that is being actively developed,
eventually needs to be revisited from scratch.
>
> But second to this, I think Johns ambitions are
> incompatible with FreeBSDs and consequently, it would probably be
> a bad idea.
>
Maybe, but I *am* working on a scalable and forward looking kernel
that will perform about the same as a conventional kernel, except
where the conventional kernel doesn't perform well at all. The
abstractions that we are working on, work both on PC's, on SMP
PC's, multiple machines (acting essentially as one machine), and
even heterogeneous machines (in a limited fashion.) One requirement
will be *BSD binary (and perhaps Linux binary) emulation (an
additional API will be there to support drivers and other native
applications, but not be the primary application API.) Also,
there is going to be emulation of internal BSD kernels adequate
to support significant sections of filesystem, and the
networking stack. That emulation isn't native, but such
emulation will be run as a kernel process. (Note the definitions
of "process" and "threads" are very different with this kernel
compared to conventional kernels. VM is also very different,
and it appears that some amazing breakthroughs have been made
in that area in the last few days. :-)). Those breakthroughs
are mostly in that of "attitude" and not implementation yet,
but it requires the "attitude" sort of breakthrough for
significant progress.
The emulation becomes much more sane, when it is recognized that
kernel processes can have their own VM (or not.) Kernel threads
might reside in their own processes, or not. Kernel threads do
not necessarily incur the overhead of conventional kernel processes
in conventional kernels. Drivers can reside in their own VM
space or not, and are multi-threaded by their very nature. The
Heidemann framework seems to be naturally supported by this kernel,
even though we won't have that initially. The kernel will be
^^^^^^^^^^^^^^^^^^
hosted with *BSD servers initially (it is appearing that *BSD
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
will be able to support a machine environment for the kernel),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
but will eventually be able to run entirely on it's own as a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
server. This OS will be an obvious choice for anything between
^^^^^^
MASSIVE server complexes and NC's. The hosting of the kernel on *BSD
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
will allow much accelerated development without waiting for filesystem
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
or driver technology to materialize. The goal is for booting within
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
one month, but of course, that is very limited in features, and the
drop-dead for a bootable kernel is two months.
The questions being answered are being reviewed anew, and as I
have stated before, continuing to force the issue (SMP) with the
existing structure, only ends up with a structure that has been
forced into a kernel. Concurrency and RT (which also includes
things like proper multimedia streaming, etc) are very limited
with current kernels, and adding a different priority scheduling
scheme doesn't really fix any significant RT problems.
In almost any technology business, part of the formula requires the
support of forward looking work. If the support is used as some
control of future direction, that can be used to advantage.
I am also Bcc: this to our mailing list, not for discussion,
but there are some new ideas in this message (as underlined), and
just want to make those ideas available to the other contributors.
Also, it is as a courtesy to them.
--
John | Never try to teach a pig to sing,
dyson@iquest.net | it makes one look stupid
jdyson@nc.com | and it irritates the pig.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806212245.RAA07936>