From 0445f54d5b9717a84a5ff159e97ac5398f4e0df0 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 6 Dec 2008 15:11:03 +0100 Subject: Formatting. --- microkernel/viengoos.mdwn | 10 +++--- microkernel/viengoos/documentation.mdwn | 60 ++++++++++++++++----------------- microkernel/viengoos/projects.mdwn | 12 +++---- 3 files changed, 41 insertions(+), 41 deletions(-) diff --git a/microkernel/viengoos.mdwn b/microkernel/viengoos.mdwn index 09043719..7e3cb01d 100644 --- a/microkernel/viengoos.mdwn +++ b/microkernel/viengoos.mdwn @@ -15,11 +15,11 @@ The source can be downloaded from the *viengoos.git* repository, cf. . You can check it out using, for example: -> git clone git://git.sv.gnu.org/hurd/viengoos.git + git clone git://git.sv.gnu.org/hurd/viengoos.git -* [[Building]] -* Running - * [[QEMU]] - * [[Hardware]] + * [[Building]] + * Running + * [[QEMU]] + * [[Hardware]] * [[Documentation]] * [[Projects]] diff --git a/microkernel/viengoos/documentation.mdwn b/microkernel/viengoos/documentation.mdwn index d7af9632..0c077df9 100644 --- a/microkernel/viengoos/documentation.mdwn +++ b/microkernel/viengoos/documentation.mdwn @@ -18,38 +18,38 @@ directory, which documents the Viengoos API and the Hurd API. Academic Papers: * [Viengoos: A Framework for Stakeholder-Directed Resource - Allocation](http://walfield.org/papers/2009-walfield-viengoos-a-framework-for-stakeholder-directed-resource-allocation.pdf). By - Neal H. Walfield. Submitted to EuroSys 2009. - -General-purpose operating systems not only fail to provide adaptive -applications the information they need to intelligently adapt, but -also schedule resources in such a way that were applications to -aggressively adapt, resources would be inappropriately scheduled. The -problem is that these systems use demand as the primary indicator of -utility, which is a poor indicator of utility for adaptive -applications. - -We present a resource management framework appropriate for traditional -as well as adaptive applications. The primary difference from current -schedulers is the use of stakeholder preferences in addition to -demand. We also show how to revoke memory, compute the amount of -memory available to each principal, and account shared -memory. Finally, we introduce a prototype system, Viengoos, and -present some benchmarks that demonstrate that it can efficiently -support multiple aggressively adaptive applications simultaneously. + Allocation](http://walfield.org/papers/2009-walfield-viengoos-a-framework-for-stakeholder-directed-resource-allocation.pdf). + By Neal H. Walfield. Submitted to EuroSys 2009. + + General-purpose operating systems not only fail to provide adaptive + applications the information they need to intelligently adapt, but + also schedule resources in such a way that were applications to + aggressively adapt, resources would be inappropriately scheduled. The + problem is that these systems use demand as the primary indicator of + utility, which is a poor indicator of utility for adaptive + applications. + + We present a resource management framework appropriate for traditional + as well as adaptive applications. The primary difference from current + schedulers is the use of stakeholder preferences in addition to + demand. We also show how to revoke memory, compute the amount of + memory available to each principal, and account shared + memory. Finally, we introduce a prototype system, Viengoos, and + present some benchmarks that demonstrate that it can efficiently + support multiple aggressively adaptive applications simultaneously. * [Improving Usability via Access Decomposition and Policy Refinement with Marcus - Brinkmann](http://walfield.org/papers/20070104-walfield-access-decomposition-policy-refinement.pdf). By - Neal H. Walfield and Marcus Brinkmann. Technical report + Brinkmann](http://walfield.org/papers/20070104-walfield-access-decomposition-policy-refinement.pdf). + By Neal H. Walfield and Marcus Brinkmann. Technical report (submitted to HotOS 2007). -Commodity operating systems fail to meet the security, resource -management and integration expectations of users. We propose a unified -solution based on a capability framework as it supports fine grained -objects, straightforward access propagation and virtualizable -interfaces and explore how to improve resource use via access -decomposition and policy refinement with minimum interposition. We -argue that only a small static number of scheduling policies are -needed in practice and advocate hierarchical policy specification and -central realization. + Commodity operating systems fail to meet the security, resource + management and integration expectations of users. We propose a unified + solution based on a capability framework as it supports fine grained + objects, straightforward access propagation and virtualizable + interfaces and explore how to improve resource use via access + decomposition and policy refinement with minimum interposition. We + argue that only a small static number of scheduling policies are + needed in practice and advocate hierarchical policy specification and + central realization. diff --git a/microkernel/viengoos/projects.mdwn b/microkernel/viengoos/projects.mdwn index a2e9f48a..e4599dc1 100644 --- a/microkernel/viengoos/projects.mdwn +++ b/microkernel/viengoos/projects.mdwn @@ -10,9 +10,9 @@ is included in the section entitled Some projects: -* Minor: +# Minor -** New hash function +## New hash function The current hash function in libhurd-ihash results in a lot of collisions when the hash table is 80% full. To overcome this, we keep @@ -22,11 +22,11 @@ appropriate in the general case or one that works well in a relevant, specific case, e.g., viengoos/object.c uses a hash to find the object corresponding to a frame, which is keyed on its physical address. -* Major: +# Major -* Thesis: +# Thesis -** Capability aware compiler +## Capability aware compiler Modify, e.g., gcc to understand capability semantics and teach gcc how -to optimize it, e.g., how to batch and combine calls. \ No newline at end of file +to optimize it, e.g., how to batch and combine calls. -- cgit v1.2.3