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
|
# <a name="Next_Hurd"> Next Hurd </a>
There is an effort to create a completely new system design (for now called ngHurd, or Hurd-ng or HurdNG), which originated from the Hurd/L4 port.
The original Hurd/L4, which was meant to be mostly a direct port of the existing Hurd design to a new microkernel, has been abandoned by it's main developers, because some technical issues with the L4 Pistachio kernel turned out to be very fundamental. While reeveluating the design (and upcoming new L4 variants), the developers picked up some new ideas, and decided that now they rather want to work on a completely different design, which combines some of the original Hurd ideas with concepts from Jonathan Shapiro's high security EROS and Coyotos systems.
There has been numerous endless discussions on the l4-hurd mailing list about these new ideas. This page tries to sum up the major discussions.
## <a name="Why_ngHurd"> Why ngHurd </a>
This section explains the motivations behind the new design:
* [[IssuesWithMach]]
* [[IssuesWithL4Pistachio]]
* [[LimitationsOfOriginalHurdDesign]]
## <a name="Work_already_done"> Work already done </a>
There is a [draft specification](http://www.marcus-brinkmann.org/hurd-ng.pdf) of the ngHurd interfaces by Marcus Brinkmann and Neal H. Walfield. NOTE: This is **very early** draft work and cannot be expected to be anything near complete.
A position paper is in work but no draft has been made public, yet.
## <a name="Subjects"> Subjects </a>
### <a name="Design_processus"> Design processus </a>
* [[DesignGoals]]
* [[RequirementsForUser]]
* [[DesignPrinciples]]
* [[Philosophy]]
### <a name="Concepts"> Concepts </a>
* [[CapabilityBasedMicrokernel]]
* [[FirstClassReceiveBuffer]]
* [[PowerBox]]
* [[WhatIsACapability]]
* [[WhatIsAConstructor]]
* [[WhatIsASpacebank]]
* [[TrivialConfinementVsConstructorVsFork]]
* [[CopyVsRevocableCopyVsMap]]
* [[SetuidVsConstructor]]
* [[HurdishApplicationsForPersistence]]
* [[WhatsInAGroup]]
* [[ThePolycastInterface]]
* [[PermissionBits]]
* [[CancellationForwarding]]
### <a name="Problems_to_solve"> Problems to solve </a>
* [[HowMuchConfinementDoWeWant]]
* [[SharedLibraries]]
* [[PathMax]]
### <a name="Implementation"> Implementation </a>
* [[ChoiceOfMicrokernel]]
* [[HurdInterafaces]]
* [[PosixLayer]]
* [[SystemStructure]]
### <a name="Organization"> Organization </a>
Summaries should obey the following structure:
* if there is a consensus, it is clearly described
* if controversial points remain, there are also described after the consenus
* if no choice has been clearly made, all valid positions are descrbied
* withdrawed and invalid positions (prooved wrong, unrealistic, contradictory to some design principle, etc.) should be described only very briefly, and developed in a separate article
Each time a point seems to be overly long with respect to the rest of the article, it should be summarized in place and developed in a separate article.
-- [[Main/NowhereMan]] - 21 Apr 2006
|
