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-
