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
|
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|mailinglists]] about these new ideas. This page tries to
sum up the major discussions.
# Why ngHurd
This section explains the motivations behind the new design:
* [[IssuesWithMach]]
* [[IssuesWithL4Pistachio]]
* [[LimitationsOfOriginalHurdDesign]]
# Work already done
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 available.
# Subjects
## Design processus
* [[DesignGoals]]
* [[RequirementsForUser]]
* [[DesignPrinciples]]
* [[Philosophy]]
## Concepts
* [[CapabilityBasedMicrokernel]]
* [[FirstClassReceiveBuffer]]
* [[PowerBox]]
* [[WhatIsACapability]]
* [[WhatIsAConstructor]]
* [[WhatIsASpacebank]]
* [[TrivialConfinementVsConstructorVsFork]]
* [[CopyVsRevocableCopyVsMap]]
* [[SetuidVsConstructor]]
* [[HurdishApplicationsForPersistence]]
* [[WhatsInAGroup]]
* [[ThePolycastInterface]]
* [[PermissionBits]]
* [[CancellationForwarding]]
## Problems to solve
* [[HowMuchConfinementDoWeWant]]
* [[SharedLibraries]]
* [[PathMax]]
## Implementation
* [[ChoiceOfMicrokernel]]
* [[HurdInterafaces]]
* [[PosixLayer]]
* [[SystemStructure]]
## Use Cases
_please move me somewhere better! [[SamMason]]_
* [[UseCaseUserFileSystem]]
* [[UseCasePrivateKeys]]
## Organization
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.
|
