[coyotos-dev] Can we really think at a new OS design nowadays ?

[Haplo]

Besides all that, I think you're missing the point. Under all the  
coyotos and eros code still lies keykos. In reality, coyotos isn't a  
'new os' really, it's just an optimized and improved version of  
keykos. However, the real question is 'does it matter?'. The answer,  
in all certainty, is no. If you'll pay closer attention, linux hasn't  
really changed much in years and still generally uses Torvald's  
kernel. Commercial OS's were using crappy monokernels up until  
recently, and now they're using crappy mach based 'hybrid' kernels.  
So, in conclusion, right now software engineering is moving backwards  
at an alarming speed. Commercial OS vendors attempt to cram as much  
code as possible into their OS until it crashes so much they're  
forced to reach back in time and pick out an OS/KOS that sucks less  
than their current design enough so to allow them to continue their  
trash pattern.

To that effect, coyotos is not affected since it's being developed  
for mission critical/embedded devices, which don't tolerate such  
practices. However, sadly, coyotos is unlikely to find it's way into  
a commercial OS any time soon, simply because of the amount of work  
required for that and the fact that nobody outside of the most elite  
and well educated users care.


On Aug 6, 2006, at 3:51 PM, Neal H. Walfield wrote:

> At Sun, 6 Aug 2006 09:52:51 +1000,
> Benno wrote:
>> On Sat Aug 05, 2006 at 19:50:05 +0200, Guillaume FORTAINE wrote:
>>>
>>> Abstraction will be the solution,
>>
>> Doesn't the research of Engler show us that abstraction in operating
>> system design is bad?
>
> I think it would be fair to argue that this is perhaps the hypothesis
> which drove the Exokernel research, however, it is unclear to me that
> the research actually proves.
>
> In "Application Performance and Flexibility on Exokernel Systems,"
> Kaashoek et al. state that hardware page tables, although they impose
> policy and appear to restrict application freedom, do not actually
> significantly reduce application flexibility:
>
>   "Unlike the MIPS architecture, the x86 architecture defines the
>   page-table structure.  Since x86 TLB refills are handled in
>   hardware, this structure cannot be overridden by applications. . . .
>   Although these restrictions make Xok less extensible than Aegis,
>   they simplify the implementation of libOSes with only a small
>   reduction in application flexiblity (9)."
>
> In fact, it simplified thigs:
>
>   "User-level page tables made the implementation of libOSes tricky on
>   Aegis; since the x86 has hardware page tables, this issue
>   disappeared on Xok/ExOS (16)."
>
> I draw from this that eliminating abstractions simply to eliminate
> abstractions misses an important point: some polices introduced via
> mechanism have negligible negative impact on performance and some such
> policies actually have positive impact (e.g. code simplification).
> This observation supports Liedtke in his challenge of the Exokernel
> architecture in "On u-Kernel Construction:"
>
>   "In contract to our approach [L4], [Exokernel] is based on the
>   philosophy that a kernel should /not/ provide abstractions but only
>   a minimal set of primitives.  Consequently, the Exokernel interface
>   is architecture dependent . . .  We believe that dropping the
>   abstractional [sic] approach could only be justified by substantial
>   performance gains. . . . It might turn out that the right
>   abstractions are even more efficient than securely multiplexing
>   hardware primitives or, on the other hand, that abstractions are too
>   inflexible."
>
> Neal
> _______________________________________________
> coyotos-dev mailing list
> coyotos-dev at smtp.coyotos.org
> http://www.coyotos.org/mailman/listinfo/coyotos-dev