From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <20181009001435.B6DDA156E40C@mail.bitblocks.com> In-Reply-To: <20181009001435.B6DDA156E40C@mail.bitblocks.com> From: Christopher Nielsen Date: Mon, 8 Oct 2018 18:34:05 -0700 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="00000000000080303d0577c1bd63" Subject: Re: [9fans] PDP11 (Was: Re: what heavy negativity!) Topicbox-Message-UUID: e8fbc4ec-ead9-11e9-9d60-3106f5b1d025 --00000000000080303d0577c1bd63 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 8, 2018, 17:15 Bakul Shah wrote: > On Mon, 08 Oct 2018 19:03:49 -0400 Dan Cross wrote: > > > > plan9 is breathtakingly elegant, but this is in no small part because as > a > > research system it had the luxury of simply ignoring many thorny problems > > that would have marred that beauty but that the developers chose not to > > tackle. Some of these problems have non-trivial domain complexity and, > > while "modern" systems are far too complex by far, that doesn't mean that > > all solutions can be recast as elegantly simple pearls in the plan9 > style. > > One thing I have mused about is recasting plan9 as a > microkernel and pushing out a lot of its kernel code into user > mode code. It is already half way there -- it is basically a > mux for 9p calls, low level device drivers, VM support & some > process related code. Such a redesign can be made more secure > and more resilient. The kind of problems you mention are > easier to fix in user code. Different application domains may > have different needs which are better handled as optional user > mode components. > > Said another way, keep the good parts of the plan9 design and > reachitect/reimplement the kernel + essential drivers/usermode > daemons. This is unlikely to happen (without some serious > funding) but still fun to think about! If done, this would be > a more radical departure than Oberon-7 compared to Oberon but > in the same spirit. > I've mused about that also. My problem has been finding the time. I think it would be a worthwhile project. Not entirely unrelated, I've been tinkering with seL4. > --00000000000080303d0577c1bd63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, = Oct 8, 2018, 17:15 Bakul Shah <ba= kul@bitblocks.com> wrote:
On= Mon, 08 Oct 2018 19:03:49 -0400 Dan Cross <crossd@gmail.com> wrote= :
>
> plan9 is breathtakingly elegant, but this is in no small part because = as a
> research system it had the luxury of simply ignoring many thorny probl= ems
> that would have marred that beauty but that the developers chose not t= o
> tackle. Some of these problems have non-trivial domain complexity and,=
> while "modern" systems are far too complex by far, that does= n't mean that
> all solutions can be recast as elegantly simple pearls in the plan9 st= yle.

One thing I have mused about is recasting plan9 as a
microkernel and pushing out a lot of its kernel code into user
mode code.=C2=A0 It is already half way there -- it is basically a
mux for 9p calls, low level device drivers, VM support & some
process related code.=C2=A0 Such a redesign can be made more secure
and more resilient.=C2=A0 The kind of problems you mention are
easier to fix in user code. Different application domains may
have different needs which are better handled as optional user
mode components.

Said another way, keep the good parts of the plan9 design and
reachitect/reimplement the kernel + essential drivers/usermode
daemons.=C2=A0 This is unlikely to happen (without some serious
funding) but still fun to think about!=C2=A0 If done, this would be
a more radical departure than Oberon-7 compared to Oberon but
in the same spirit.

I've mused about that also. My problem has been find= ing the time. I think it would be a worthwhile project.

Not entirely unrelated, I've been tinke= ring with seL4.
--00000000000080303d0577c1bd63--