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
|
# <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>
A [position paper](http://walfield.org/papers/20070104-walfield-access-decomposition-policy-refinement.pdf) by Marcus Brinkmann and Neal H. Walfield can be found.
A draft specification of the Hurd-NG interfaces has been, but is no longer, available.
A critique of the original Hurd is work in progress, but no draft has been made available, 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="Use_Cases"> Use Cases </a>
_please move me somewhere better! [[SamMason]]_
* [[UseCaseUserFileSystem]]
* [[UseCasePrivateKeys]]
### <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
|
