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
|
# <a name="Design_Goals"> Design Goals </a>
## <a name="The_Position_Paper"> The Position Paper </a>
_Improving Usability via Access Decomposition and Policy Refinement_ tries to capture technical objectives. As has been stated by Neal in [2], these are a number of scenarios we are interested in addressing:
* security: programs are not users; they should be constrained according to the user's intents
* resource management
* efficiency: facilitate use of local knowledge
* soft real-time: expose virtualized resources with useful access case characteristics
* integration: safe extension of the system
## <a name="The_original_list"> The original list </a>
These goals have been initially proposed by Bas Wijnen [1]. The list here is a slightly modified form, I tried to incorporate the content of the mailing list discussion. It has to be noted that there is no consensus about this list. There have been objections about both the number of goals stated and specific goals themselves.
## <a name="Essential_Goals"> Essential Goals </a>
* stability
* robustness
* resource accountability
* confinement
* support for most legacy applications
* extensibility
* no ACLs
### <a name="On_Extensibility"> On Extensibility </a>
Extensibility has often been a strong argument to support the multiserver approach. Therefore, I think, it has been rated to be an essential goal in our (preliminary) list, too. However, it has been [suggested](http://citeseer.ist.psu.edu/druschel97extensible.html) that this argument is of few or no interest for a general purpose OSes: it is argued that the benefits of extensible kernels can be migrated to conventional ones by defining exactly what the extension requires. "Conventional kernel" is here probably to be interpreted as "monolithic kernel". From the above, I think the first (naive) conclusion that could be drawn would be to abandon the multiserver approach and extensibility goal.
However, I do believe there are benefits in multiserver environments you cannot get in a monolithic one, namely enhanced security and stability through protection boundaries. Also, whilst wanting to become adopted as general purpose OS, ngHurd still strives to allow for research also, so even according to the above-referenced paper extensibility is to be one of its goals.
Therefore, I'd want to propose to weaken the impact of extensibility on the design, by lowering it to the category "Regular Goals". -- [[Main/TomBachmann]] - 13 Dec 2006
## <a name="Regular_Goals"> Regular Goals </a>
* confinement with endogenous verification
* soft real time
* setting diverse resource distribution policies
* persistent sessions for users
## <a name="Optional_Goals"> Optional Goals </a>
* small memory footprint
* support for all POSIX applications
* persistence
----
* [1] <http://lists.gnu.org/archive/html/l4-hurd/2005-11/msg00037.html>
* [2] <http://lists.gnu.org/archive/html/l4-hurd/2007-01/msg00122.html>
-- [[Main/TomBachmann]] - 29 Apr 2006
|
