1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
|
[[!meta copyright="Copyright © 2009, 2011 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
[[!meta title="What happened to the L4 / Coyotos / Viengoos microkernels?"]]
Encountering a number of fundamental design issues with the Mach microkernel
(mostly with resource management),
some of the Hurd developers began experimenting with using other microkernels for the Hurd.
The first attempt was reimplementing the Hurd on the L4 (Pistachio) microkernel.
This got going around 2003/2004,
and got pretty far (running some simple POSIX programs, such as "banner");
however over time some lingering design issues turned out to be fundamental problems:
the original L4 is not suitable for building object capability systems like the Hurd.
Thus development was aborted in 2005.
Following that, an attempt was started to use the kernel of the Coyotos system.
As Coyotos is an object-capability system througout,
the microkernel would obviously be more suitable for this purpose;
and it looked pretty promising in the beginning.
However, further investigations found
that there are some very fundamental philosophical differences
between the Coyotos and Hurd designs;
and thus this this attempt was also abandonned, around 2006/2007.
(This time before producing any actual code.)
By now there were some new L4 variants available,
which added protected IPC paths and other features necessary for object capability systems;
so it might be possible to implement the Hurd on top of these.
However, by that time the developers concluded that microkernel design and system design
are interconnected in very intricate ways,
and thus trying to use a third-party microkernel will always result in trouble.
So Neal Walfield created the experimental [[Viengoos|microkernel/viengoos]] kernel instead --
based on the experience from the previous experiments with L4 and Coyotos --
for his research on resource management.
Currently he works in another research area though, and thus Viengoos is on hold.
Note that while none of the microkernel work is active now,
the previous experiments already yielded a lot of experience,
which will be very useful in the further development/improvement
of the mainline (Mach-based) Hurd implementation.
<!--
---
IRC, #hurd, 2011-01-12.
[[!taglink open_issue_documentation]]
<Pete-J> Hello i am just curious of the development of Hurd - what's the
current mission on the microkernel i see projects like l4 and viengoos,
will one of these projects replace Mach? or will you stick with Mach
<Pete-J> as i understand is that Mach is a first generation microkernel
that's very old in design and causes alot of issues
<Pete-J> that's where l4 and viengoos comes in - they are trying to be the
next generation Mach - am i correct?
<neal> l4 is not a drop in replacement for Mach
<neal> it doesn't actually do much resource management
<neal> for instance, you still have to implement a memory manager
<neal> this is where several issues are with Mach
<neal> l4 doesn't address those issues; it punts to the operating system
<Pete-J> and what about viengoos?
<neal> it's unfinished
<neal> and it implemented some untested ideas
<neal> i.e., parts of viengoos were research
<neal> there has not been a sufficient evaluation of those ideas to
determine whether they are a good approach
<Pete-J> meaning that viengoos is a research kernel that could aid Mach?
<neal> I'm not sure I understand your question
<Pete-J> Well is viengoos trying to be a replacement for Mach, or will
viengoos be an experiment of new ideas that could be implemented in Mach?
<Pete-J> i am sorry for my limited english
<neal> viengoos was designed with a Hurd-like user-land in mind
<neal> in that sense it was a Mach replacement
<neal> (unlike L4)
<neal> viengoos consisted of a few experiments
<neal> one could implement them in mach
<neal> but it would require exposing new interfaces
<neal> in which case, I'm not sure you could call the result Mach
<Pete-J> Well as i understand you develop two microkernels side by side,
wouldnt it be more effective to investigate viengoos more and maybe move
the focus to viengoos?
<antrik> no
<antrik> having something working all the time is crucial
<antrik> it's very hard to motivate people to work on a project that might
be useful, in a couple of years, perhaps...
<Pete-J> Well Mach is meant to be replaced one day - i see no reason to
keep on developing it just because it works at this moment
<Pete-J> *if Mach is meant to be replaced
<antrik> it's not at all clear that it will be replaced by something
completely different. I for my part believe that modifying the existing
Mach is a more promising approach
<Pete-J> as i understand man power is something you need - and by spreading
out the developers just makes the progress more slow
<antrik> but even if it *were* to be replaced one day, it doesn't change
the fact that we need it *now*
<antrik> all software will be obsolete one day. doesn't mean it's not worth
working on
<antrik> the vast majority of work is not on the microkernel anyways, but
on the system running on top of it
<Pete-J> ahh i see
<antrik> manpower is not something that comes from nowhere. again, having
something working is crucial in a volunteer project like this
<antrik> there are no fixed plans
-->
|
