Re: Coyotos

[olafBuddenhagen]

Hi,

On Wed, Sep 23, 2009 at 01:15:36AM -0700, Jonathan S. Shapiro wrote:

> It is true that the Coyotos *system* considers encapsulation of data
> to be a fundamental requirement. If you cannot tell where data can go,
> you cannot determine the scope and consequences of errors. For this
> reason, the Coyotos *system* constructs confined subsystems as a
> default.
> 
> However, the Coyotos *kernel* does not embed this assumption. It is
> perfectly possible to build other *systems* on top of the Coyotos
> *kernel*. Given that l4-hurd is trying to be something very different
> from Coyotos, it was never really my expectation that l4-hurd would
> end up using much of the Coyotos *system*. The Coyotos kernel remains
> a fairly high-performance alternative, I am not aware of any l4-hurd
> goal that it fails to support, and I am not aware of any l4-hurd
> anti-goal that it imposes.
> 
> So if Coyotos was abandoned for the reasons you suggest, then it was
> abandoned for the wrong reasons.

If this indeed had been the only problem, you are probably right that it
would still have been possible to build a Hurd-like system on top of
Coyotos kernel, while ignoring the space bank and constructor. (Though
AIUI that was not what Marcus and Neal were originally planning...)

But it wasn't the only problem. Other issues were the fully synchnonous
IPC, which is unsuitable for certain use cases -- including situation
common in a UNIX environment; and the completely different resource
management approach.

I'm not sure whether the persistence mechanism was also a concern
already when this decision was made, or it was only later that Marcus
changed his mind on that...

These are the issues I gathered from various discussions; there might
have been others that I didn't realize, not having looked at various
details.

-antrik-