Soma-notes - User contributions [en]

MashupOS

2012-10-04T12:28:54Z

Asoknack:

Protection and communication abstractions for web browsers in MashupOS
* Where was it written - for OS people
** Proceedings of twenty-first ACM SIGOPS symposium on Operating systems principles
Pages 1-16
** Not security and not web people
* What the purposed
** Written by the same people as subspace paper
*** Which came first ?
** Sandbox EVERYTHING <-- solution to everything
* What the implemented
** Sandbox
*** private that is hosted at and belongs to the integrator ??
** Opensandbox
*** Ment for any scripted hosted on any domain
** Service Instance
*** think starting a new process in linux - each alocated it's own resources
*** each service request
** Commservice request - aka "Ports"
*** Allows separate components to talk to each other threw the parent , but never directly child to child
** friv
*** the display driver each service instances needs it own display aka friv
** vop <-- Do we want to talk about
** sop <-- Do we want to talk about
* What was implemented
** Proxy server and MME filter
**
* What the testing was
** Running speed tests not security test , Anil said WHY ? mabey because OS conference cares about speed
** Open sandbox was not implemented
** only one service instance per friv
* Conclusions
** Mostly a theoretical paper
*** But interesting
** Notes
*** Do we want to show figure 2 <---- for what they did
*** Do we want to show figure 3 <--- for what they did and how it works

MashupOS

2012-10-04T12:26:30Z

Asoknack:

Protection and communication abstractions for web browsers in MashupOS
* Where was it written - for OS people
** Proceedings of twenty-first ACM SIGOPS symposium on Operating systems principles
Pages 1-16
** Not security and not web people
* What the purposed
** Written by the same people as subspace paper
*** Which came first ?
** Sandbox EVERYTHING <-- solution to everything
* What the implemented
** Sandbox
*** private that is hosted at and belongs to the integrator ??
** Opensandbox
*** Ment for any scripted hosted on any domain
** Service Instance
*** think starting a new process in linux - each alocated it's own resources
*** each service request
** Commservice request - aka "Ports"
*** Allows separate components to talk to each other threw the parent , but never directly child to child
** friv
*** the display driver each service instances needs it own display aka friv
** vop <-- Do we want to talk about
** sop <-- Do we want to talk about
* What was implemented MME filter
** Proxy server and
**
* What the testing was
** Running speed tests not security test , Anil said WHY ? mabey because OS conference cares about speed
** Open sandbox was not implemented
** only one service instance per fric
* Conclusions
** Mostly a theoretical paper
*** But interesting
** Notes
*** Do we want to show figure 2 <---- for what they did
*** Do we want to show figure 3 <--- for what they did and how it works

MashupOS

2012-10-03T15:09:00Z

Asoknack:

MashupOS

2012-10-03T14:37:06Z

Asoknack: Added Basic framework

OSWebSec: Web Mashups

2012-10-03T14:19:54Z

Asoknack:

[[MashupOS]]

OSWebSec: Web Mashups

2012-10-03T14:18:29Z

Asoknack:

[[WebOS]]

OSWebSec: Web Mashups

2012-10-03T14:18:08Z

Asoknack: Created page with "wikipedia:WebOS"

[[wikipedia:WebOS]]

COMP 3000 Essay 2 2010 Question 7

2010-11-25T21:19:36Z

Asoknack: /* References */

==Paper==
===Ad Hoc Synchronization Considered Harmful===
Weiwei Xiong
University of California, San Diego

Soyeon Park, Jiaqi Zhang, Yuanyuan Zhou
University of Illinois at Urbana-Champaign

Zhiqiang Ma
Intel
==Research Problem==
As the computer industry continues to shift towards multicore processors, concurrent programming and the use of multithreaded designs has increased to keep up with this growing trend. Multithreaded applications can be found in a variety of popular applications today as they take advantage of the multithreaded approach. However, the concepts behind concurrent programming bring with them a host of potential dangers in the form of race conditions and deadlocks resulting from bad programming design and threads accessing shared memory. Fortunately, there are well known and standard methods for dealing with these problems, i.e synchronization primitives. But in real world situations, due to a variety of reasons, as we shall see, programmers often implement their own "ad hoc" synchronizations that eschew common design standards. Ad hoc synchronizations are not well documented and are not discovered by traditional tools for race conditions that look for standard synchronization primitives.

This paper addresses these concerns in two regards, first it details a thorough study of ad hoc synchronizations. It details their nature, dangers, impact on bug detection tools and prevalence in several major open-source applications. Secondly, it introduces SyncFinder, a program that detects all ad hoc synchronizations and automatically annotates the source code where ad hoc sychnronizations are found. This can see use in conjunction with other data race checkers to improve accuracy and to build custom tools for finding deadlocks and bad programming practices.

With detailed analysis of ad hoc synchronization and study of their occurrences in several applications, the research ultimately concludes that they are harmful and should be removed. At the same time, SyncFinder detects and documents ad hoc synchronizations in the source code enabling programmers for the first time to easily track and remove them.

==Background Concepts==
===Race conditions, deadlocks===
Race conditions are an unintended side-effects of programming in concurrent systems, they occur when two or more processes have access to a shared resource and at least one of them have write privilege. This leads to processes modifying the data that all processes share as other may be reading them and results in the reading of stale/incorrect data. They will occur during the execution of the program and often times very difficult to detect or manipulate data in subtle ways.

Deadlock is when two or more processes share a resource and each process is waiting on the other processes to unlock the resource. It becomes a circular chain and no process can continue.

Both these issues occur in concurrent programming and although there are no general solutions for deadlock[[#Foot9|9]], there are suitable methods for dealing with them, and in the case of race conditions, using mutual exclusion locks and synchronization primitives can prevent race conditions. But no programmer is infallible and so there is always the issue of race conditions and deadlocks present in production code.
===Ad Hoc Synchronization===
Ad hoc synchronizations are loops called sync loops that continue until certain conditions are met via outside variables called sync variables. They are designed to control the flow of thread execution much like locking and unlocking of resources. There can be multiple sync variables in a sync loop and they can have multiple exit conditions and dependencies. The diversity of the sync loops, their dependencies and execution paths leads to difficulty in finding them.
===Synchronization primitives===
Synchronization variables act as barriers to memory that prevent threads from accessing the same shared resource concurrently[[#Foot8|8]]. They come in many forms such as mutexes and condition variables.
Mutexes are mutual exclusive locks that threads employ to lock a resource that they need. No other threads can access them at that point. Once they are finished, they release the lock and the other threads can then lock and access the resource.
Condition variables are variables that will block the thread until a certain condition is met. This allows the thread to only execute when it is safe to perform its operation.

==Contribution==
Intro to the study of the major applications and what they found

===Findings===
1.they are prevalent, all applications had them

2. hard to find

3. error prone

4.effect other bug detection

5. They are diverse. Different forms, multiple exits and dependencies

Reasons behind why people use ad hoc synchronization and possible improvements over them ie Synchronization primitives

===SyncFinder===
Intro to what it is and what it does
====How it works====
1. find loops

2. identify sync loops

3. EDV analysis

4. Pruning

5. Annotation of found sync

====Uses====
1. A tool to detect bad practices

2. Extensions to data race detection

====Accuracy====

====Related Work and similar tools====
There has been attempts to remove synchronization issues entirely from concurrent programming, such as transactional memory[[#Foot1|1]], a lock-free synchronization that does not require mutexes, and avoids having to use lock, unlock operations. Other attempts have been made to remove bugs that would otherwise be safe from data races but are are still at risk of unintended effects from thread interactions, such as Atomizer[[#Foot2|2]], a dynamic atomicity checker.

There are tools that detect data races such as CHESS[[#Foot3|3]], a dynamic data race checker that runs through all possible thread execution paths and CTrigger[[#Foot4|4]], a tool that checks for atomicity violations. The problem with these programs is that they only look for standard synchronization methods and structures, such as lock() and cond_wait(). They are not looking for ad hoc synchronizations.

A similar tool to SyncFinder exists that can detect simple spinning, also an ad hoc synchronization[[#Foot5|5]], but it only detects simple spinning and not the more complicated ad hoc variations.

Several studies on bug characteristics[[#Foot6|6]] and concurrency bugs[[#Foot7|7]] have been composed. This paper complements these studies to better understand the nature of ad hoc synchronizations and their occurrence in concurrent programs.

==Critique==
1. Uses static approach, dynamic would be better
* As stated in the paper, dynamic introduces run-time overhead and is not guaranteed to find if not executed in the test cases

2. not entirely accurate, some false positives.

3. In terms of style, lots of unnecessary repetition

==References==
1 M Herlihy and J.E.B. Moss, 2NA0. Transactional Memory:
Architectural Support for Lock-Free Data Structures. [online] Available at: <http://www.cs.brown.edu/~mph/HerlihyM93/herlihy93transactional.pdf> [Accessed 23 November 2010].

2 C Flanagan and S N Freund, 2NA0. Atomizer: A Dynamic Atomicity Checker For Multithreaded Programs (Summary). [online] Company(optional) Available at: <http://www.cs.williams.edu/~freund/papers/atomizer-padtad.pdf> [Accessed 23 November 2010].

3 T Ball,M Musuvathi and S Qadeer, 2NA0. CHESS: A Systematic Testing Tool for Concurrent. [online] Company(optional) Available at: <http://research.microsoft.com/pubs/70509/tr-2007-149.pdf> [Accessed 23 November 2010].

4 Author, 2NA0. Title. [online] Company(optional) Available at: <http://pages.cs.wisc.edu/~shanlu/paper/asplos092-zhou.pdf> [Accessed 23 November 2010].

5 LI, T., LEBECK, A. R., AND SORIN, D. J. Spin detection hardware for improved management of multithreaded systems. IEEE Transactions on Parallel and Distributed Systems PDS-17, 6 (June 2006), 508–521.

6 Author, 2NA0. Title. [online] Company(optional) Available at: <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf> [Accessed 23 November 2010].

7 Author, 2NA0. Title. [online] Company(optional) Available at: <[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf]> [Accessed 23 November 2010].

8 Author, 2NA0. Title. [online] Company(optional) Available at: <[http://www.usenix.org/events/bsdcon/full_papers/baldwin/baldwin_html/node5.html]> [Accessed 23 November 2010].

9 Author, 2010. Title. [online] Company(optional) Available at: <http://homeostasis.scs.carleton.ca/wiki/index.php/Basic_Synchronization_Principles> [Accessed 23 November 2010].

COMP 3000 Essay 2 2010 Question 7

2010-11-25T21:01:49Z

Asoknack: /* References */

==Paper==
===Ad Hoc Synchronization Considered Harmful===
Weiwei Xiong
University of California, San Diego

Soyeon Park, Jiaqi Zhang, Yuanyuan Zhou
University of Illinois at Urbana-Champaign

Zhiqiang Ma
Intel
==Research Problem==
As the computer industry continues to shift towards multicore processors, concurrent programming and the use of multithreaded designs has increased to keep up with this growing trend. Multithreaded applications can be found in a variety of popular applications today as they take advantage of the multithreaded approach. However, the concepts behind concurrent programming bring with them a host of potential dangers in the form of race conditions and deadlocks resulting from bad programming design and threads accessing shared memory. Fortunately, there are well known and standard methods for dealing with these problems, i.e synchronization primitives. But in real world situations, due to a variety of reasons, as we shall see, programmers often implement their own "ad hoc" synchronizations that eschew common design standards. Ad hoc synchronizations are not well documented and are not discovered by traditional tools for race conditions that look for standard synchronization primitives.

This paper addresses these concerns in two regards, first it details a thorough study of ad hoc synchronizations. It details their nature, dangers, impact on bug detection tools and prevalence in several major open-source applications. Secondly, it introduces SyncFinder, a program that detects all ad hoc synchronizations and automatically annotates the source code where ad hoc sychnronizations are found. This can see use in conjunction with other data race checkers to improve accuracy and to build custom tools for finding deadlocks and bad programming practices.

With detailed analysis of ad hoc synchronization and study of their occurrences in several applications, the research ultimately concludes that they are harmful and should be removed. At the same time, SyncFinder detects and documents ad hoc synchronizations in the source code enabling programmers for the first time to easily track and remove them.

==Background Concepts==
===Race conditions, deadlocks===
Race conditions are an unintended side-effects of programming in concurrent systems, they occur when two or more processes have access to a shared resource and at least one of them have write privilege. This leads to processes modifying the data that all processes share as other may be reading them and results in the reading of stale/incorrect data. They will occur during the execution of the program and often times very difficult to detect or manipulate data in subtle ways.

Deadlock is when two or more processes share a resource and each process is waiting on the other processes to unlock the resource. It becomes a circular chain and no process can continue.

Both these issues occur in concurrent programming and although there are no general solutions for deadlock[[#Foot9|9]], there are suitable methods for dealing with them, and in the case of race conditions, using mutual exclusion locks and synchronization primitives can prevent race conditions. But no programmer is infallible and so there is always the issue of race conditions and deadlocks present in production code.
===Ad Hoc Synchronization===
Ad hoc synchronizations are loops called sync loops that continue until certain conditions are met via outside variables called sync variables. They are designed to control the flow of thread execution much like locking and unlocking of resources. There can be multiple sync variables in a sync loop and they can have multiple exit conditions and dependencies. The diversity of the sync loops, their dependencies and execution paths leads to difficulty in finding them.
===Synchronization primitives===
Synchronization variables act as barriers to memory that prevent threads from accessing the same shared resource concurrently[[#Foot8|8]]. They come in many forms such as mutexes and condition variables.
Mutexes are mutual exclusive locks that threads employ to lock a resource that they need. No other threads can access them at that point. Once they are finished, they release the lock and the other threads can then lock and access the resource.
Condition variables are variables that will block the thread until a certain condition is met. This allows the thread to only execute when it is safe to perform its operation.

==Contribution==
Intro to the study of the major applications and what they found

===Findings===
1.they are prevalent, all applications had them

2. hard to find

3. error prone

4.effect other bug detection

5. They are diverse. Different forms, multiple exits and dependencies

Reasons behind why people use ad hoc synchronization and possible improvements over them ie Synchronization primitives

===SyncFinder===
Intro to what it is and what it does
====How it works====
1. find loops

2. identify sync loops

3. EDV analysis

4. Pruning

5. Annotation of found sync

====Uses====
1. A tool to detect bad practices

2. Extensions to data race detection

====Accuracy====

====Related Work and similar tools====
There has been attempts to remove synchronization issues entirely from concurrent programming, such as transactional memory[[#Foot1|1]], a lock-free synchronization that does not require mutexes, and avoids having to use lock, unlock operations. Other attempts have been made to remove bugs that would otherwise be safe from data races but are are still at risk of unintended effects from thread interactions, such as Atomizer[[#Foot2|2]], a dynamic atomicity checker.

There are tools that detect data races such as CHESS[[#Foot3|3]], a dynamic data race checker that runs through all possible thread execution paths and CTrigger[[#Foot4|4]], a tool that checks for atomicity violations. The problem with these programs is that they only look for standard synchronization methods and structures, such as lock() and cond_wait(). They are not looking for ad hoc synchronizations.

A similar tool to SyncFinder exists that can detect simple spinning, also an ad hoc synchronization[[#Foot5|5]], but it only detects simple spinning and not the more complicated ad hoc variations.

Several studies on bug characteristics[[#Foot6|6]] and concurrency bugs[[#Foot7|7]] have been composed. This paper complements these studies to better understand the nature of ad hoc synchronizations and their occurrence in concurrent programs.

==Critique==
1. Uses static approach, dynamic would be better
* As stated in the paper, dynamic introduces run-time overhead and is not guaranteed to find if not executed in the test cases

2. not entirely accurate, some false positives.

3. In terms of style, lots of unnecessary repetition

==References==
1 M Herlihy and J.E.B. Moss, 2NA0. Transactional Memory:
Architectural Support for Lock-Free Data Structures. [online] Available at: <http://www.cs.brown.edu/~mph/HerlihyM93/herlihy93transactional.pdf> [Accessed 23 November 2010].

2 C Flanagan and S N Freund, 2NA0. Atomizer: A Dynamic Atomicity Checker For Multithreaded Programs (Summary). [online] Company(optional) Available at: <http://www.cs.williams.edu/~freund/papers/atomizer-padtad.pdf> [Accessed 23 November 2010].

3 Author, 2NA0. Title. [online] Company(optional) Available at: <http://research.microsoft.com/pubs/70509/tr-2007-149.pdf> [Accessed 23 November 2010].

4 Author, 2NA0. Title. [online] Company(optional) Available at: <http://pages.cs.wisc.edu/~shanlu/paper/asplos092-zhou.pdf> [Accessed 23 November 2010].

5 LI, T., LEBECK, A. R., AND SORIN, D. J. Spin detection hardware for improved management of multithreaded systems. IEEE Transactions on Parallel and Distributed Systems PDS-17, 6 (June 2006), 508–521.

6 Author, 2NA0. Title. [online] Company(optional) Available at: <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf> [Accessed 23 November 2010].

7 Author, 2NA0. Title. [online] Company(optional) Available at: <[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf]> [Accessed 23 November 2010].

8 Author, 2NA0. Title. [online] Company(optional) Available at: <[http://www.usenix.org/events/bsdcon/full_papers/baldwin/baldwin_html/node5.html]> [Accessed 23 November 2010].

9 Author, 2010. Title. [online] Company(optional) Available at: <http://homeostasis.scs.carleton.ca/wiki/index.php/Basic_Synchronization_Principles> [Accessed 23 November 2010].

COMP 3000 Essay 2 2010 Question 7

2010-11-25T20:58:37Z

Asoknack: /* References */

==Paper==
===Ad Hoc Synchronization Considered Harmful===
Weiwei Xiong
University of California, San Diego

Soyeon Park, Jiaqi Zhang, Yuanyuan Zhou
University of Illinois at Urbana-Champaign

Zhiqiang Ma
Intel
==Research Problem==
As the computer industry continues to shift towards multicore processors, concurrent programming and the use of multithreaded designs has increased to keep up with this growing trend. Multithreaded applications can be found in a variety of popular applications today as they take advantage of the multithreaded approach. However, the concepts behind concurrent programming bring with them a host of potential dangers in the form of race conditions and deadlocks resulting from bad programming design and threads accessing shared memory. Fortunately, there are well known and standard methods for dealing with these problems, i.e synchronization primitives. But in real world situations, due to a variety of reasons, as we shall see, programmers often implement their own "ad hoc" synchronizations that eschew common design standards. Ad hoc synchronizations are not well documented and are not discovered by traditional tools for race conditions that look for standard synchronization primitives.

This paper addresses these concerns in two regards, first it details a thorough study of ad hoc synchronizations. It details their nature, dangers, impact on bug detection tools and prevalence in several major open-source applications. Secondly, it introduces SyncFinder, a program that detects all ad hoc synchronizations and automatically annotates the source code where ad hoc sychnronizations are found. This can see use in conjunction with other data race checkers to improve accuracy and to build custom tools for finding deadlocks and bad programming practices.

With detailed analysis of ad hoc synchronization and study of their occurrences in several applications, the research ultimately concludes that they are harmful and should be removed. At the same time, SyncFinder detects and documents ad hoc synchronizations in the source code enabling programmers for the first time to easily track and remove them.

==Background Concepts==
===Race conditions, deadlocks===
Race conditions are an unintended side-effects of programming in concurrent systems, they occur when two or more processes have access to a shared resource and at least one of them have write privilege. This leads to processes modifying the data that all processes share as other may be reading them and results in the reading of stale/incorrect data. They will occur during the execution of the program and often times very difficult to detect or manipulate data in subtle ways.

Deadlock is when two or more processes share a resource and each process is waiting on the other processes to unlock the resource. It becomes a circular chain and no process can continue.

Both these issues occur in concurrent programming and although there are no general solutions for deadlock[[#Foot9|9]], there are suitable methods for dealing with them, and in the case of race conditions, using mutual exclusion locks and synchronization primitives can prevent race conditions. But no programmer is infallible and so there is always the issue of race conditions and deadlocks present in production code.
===Ad Hoc Synchronization===
Ad hoc synchronizations are loops called sync loops that continue until certain conditions are met via outside variables called sync variables. They are designed to control the flow of thread execution much like locking and unlocking of resources. There can be multiple sync variables in a sync loop and they can have multiple exit conditions and dependencies. The diversity of the sync loops, their dependencies and execution paths leads to difficulty in finding them.
===Synchronization primitives===
Synchronization variables act as barriers to memory that prevent threads from accessing the same shared resource concurrently[[#Foot8|8]]. They come in many forms such as mutexes and condition variables.
Mutexes are mutual exclusive locks that threads employ to lock a resource that they need. No other threads can access them at that point. Once they are finished, they release the lock and the other threads can then lock and access the resource.
Condition variables are variables that will block the thread until a certain condition is met. This allows the thread to only execute when it is safe to perform its operation.

==Contribution==
Intro to the study of the major applications and what they found

===Findings===
1.they are prevalent, all applications had them

2. hard to find

3. error prone

4.effect other bug detection

5. They are diverse. Different forms, multiple exits and dependencies

Reasons behind why people use ad hoc synchronization and possible improvements over them ie Synchronization primitives

===SyncFinder===
Intro to what it is and what it does
====How it works====
1. find loops

2. identify sync loops

3. EDV analysis

4. Pruning

5. Annotation of found sync

====Uses====
1. A tool to detect bad practices

2. Extensions to data race detection

====Accuracy====

====Related Work and similar tools====
There has been attempts to remove synchronization issues entirely from concurrent programming, such as transactional memory[[#Foot1|1]], a lock-free synchronization that does not require mutexes, and avoids having to use lock, unlock operations. Other attempts have been made to remove bugs that would otherwise be safe from data races but are are still at risk of unintended effects from thread interactions, such as Atomizer[[#Foot2|2]], a dynamic atomicity checker.

There are tools that detect data races such as CHESS[[#Foot3|3]], a dynamic data race checker that runs through all possible thread execution paths and CTrigger[[#Foot4|4]], a tool that checks for atomicity violations. The problem with these programs is that they only look for standard synchronization methods and structures, such as lock() and cond_wait(). They are not looking for ad hoc synchronizations.

A similar tool to SyncFinder exists that can detect simple spinning, also an ad hoc synchronization[[#Foot5|5]], but it only detects simple spinning and not the more complicated ad hoc variations.

Several studies on bug characteristics[[#Foot6|6]] and concurrency bugs[[#Foot7|7]] have been composed. This paper complements these studies to better understand the nature of ad hoc synchronizations and their occurrence in concurrent programs.

==Critique==
1. Uses static approach, dynamic would be better
* As stated in the paper, dynamic introduces run-time overhead and is not guaranteed to find if not executed in the test cases

2. not entirely accurate, some false positives.

3. In terms of style, lots of unnecessary repetition

==References==
1 M Herlihy and J.E.B. Moss, 2NA0. Transactional Memory:
Architectural Support for Lock-Free Data Structures. [online] Available at: <http://www.cs.brown.edu/~mph/HerlihyM93/herlihy93transactional.pdf> [Accessed 23 November 2010].

2 Author, 2010. Title. [online] Company(optional) Available at: <http://www.cs.williams.edu/~freund/papers/atomizer-padtad.pdf> [Accessed 23 November 2010].

3 Author, 2010. Title. [online] Company(optional) Available at: <http://research.microsoft.com/pubs/70509/tr-2007-149.pdf> [Accessed 23 November 2010].

4 Author, 2010. Title. [online] Company(optional) Available at: <http://pages.cs.wisc.edu/~shanlu/paper/asplos092-zhou.pdf> [Accessed 23 November 2010].

5 LI, T., LEBECK, A. R., AND SORIN, D. J. Spin detection hardware for improved management of multithreaded systems. IEEE Transactions on Parallel and Distributed Systems PDS-17, 6 (June 2006), 508–521.

6 Author, 2010. Title. [online] Company(optional) Available at: <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf> [Accessed 23 November 2010].

7 Author, 2010. Title. [online] Company(optional) Available at: <[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf]> [Accessed 23 November 2010].

8 Author, 2010. Title. [online] Company(optional) Available at: <[http://www.usenix.org/events/bsdcon/full_papers/baldwin/baldwin_html/node5.html]> [Accessed 23 November 2010].

9 Author, 2010. Title. [online] Company(optional) Available at: <http://homeostasis.scs.carleton.ca/wiki/index.php/Basic_Synchronization_Principles> [Accessed 23 November 2010].

COMP 3000 Essay 2 2010 Question 7

2010-11-25T20:58:15Z

Asoknack: /* References */

==Paper==
===Ad Hoc Synchronization Considered Harmful===
Weiwei Xiong
University of California, San Diego

Soyeon Park, Jiaqi Zhang, Yuanyuan Zhou
University of Illinois at Urbana-Champaign

Zhiqiang Ma
Intel
==Research Problem==
As the computer industry continues to shift towards multicore processors, concurrent programming and the use of multithreaded designs has increased to keep up with this growing trend. Multithreaded applications can be found in a variety of popular applications today as they take advantage of the multithreaded approach. However, the concepts behind concurrent programming bring with them a host of potential dangers in the form of race conditions and deadlocks resulting from bad programming design and threads accessing shared memory. Fortunately, there are well known and standard methods for dealing with these problems, i.e synchronization primitives. But in real world situations, due to a variety of reasons, as we shall see, programmers often implement their own "ad hoc" synchronizations that eschew common design standards. Ad hoc synchronizations are not well documented and are not discovered by traditional tools for race conditions that look for standard synchronization primitives.

This paper addresses these concerns in two regards, first it details a thorough study of ad hoc synchronizations. It details their nature, dangers, impact on bug detection tools and prevalence in several major open-source applications. Secondly, it introduces SyncFinder, a program that detects all ad hoc synchronizations and automatically annotates the source code where ad hoc sychnronizations are found. This can see use in conjunction with other data race checkers to improve accuracy and to build custom tools for finding deadlocks and bad programming practices.

With detailed analysis of ad hoc synchronization and study of their occurrences in several applications, the research ultimately concludes that they are harmful and should be removed. At the same time, SyncFinder detects and documents ad hoc synchronizations in the source code enabling programmers for the first time to easily track and remove them.

==Background Concepts==
===Race conditions, deadlocks===
Race conditions are an unintended side-effects of programming in concurrent systems, they occur when two or more processes have access to a shared resource and at least one of them have write privilege. This leads to processes modifying the data that all processes share as other may be reading them and results in the reading of stale/incorrect data. They will occur during the execution of the program and often times very difficult to detect or manipulate data in subtle ways.

Deadlock is when two or more processes share a resource and each process is waiting on the other processes to unlock the resource. It becomes a circular chain and no process can continue.

Both these issues occur in concurrent programming and although there are no general solutions for deadlock[[#Foot9|9]], there are suitable methods for dealing with them, and in the case of race conditions, using mutual exclusion locks and synchronization primitives can prevent race conditions. But no programmer is infallible and so there is always the issue of race conditions and deadlocks present in production code.
===Ad Hoc Synchronization===
Ad hoc synchronizations are loops called sync loops that continue until certain conditions are met via outside variables called sync variables. They are designed to control the flow of thread execution much like locking and unlocking of resources. There can be multiple sync variables in a sync loop and they can have multiple exit conditions and dependencies. The diversity of the sync loops, their dependencies and execution paths leads to difficulty in finding them.
===Synchronization primitives===
Synchronization variables act as barriers to memory that prevent threads from accessing the same shared resource concurrently[[#Foot8|8]]. They come in many forms such as mutexes and condition variables.
Mutexes are mutual exclusive locks that threads employ to lock a resource that they need. No other threads can access them at that point. Once they are finished, they release the lock and the other threads can then lock and access the resource.
Condition variables are variables that will block the thread until a certain condition is met. This allows the thread to only execute when it is safe to perform its operation.

==Contribution==
Intro to the study of the major applications and what they found

===Findings===
1.they are prevalent, all applications had them

2. hard to find

3. error prone

4.effect other bug detection

5. They are diverse. Different forms, multiple exits and dependencies

Reasons behind why people use ad hoc synchronization and possible improvements over them ie Synchronization primitives

===SyncFinder===
Intro to what it is and what it does
====How it works====
1. find loops

2. identify sync loops

3. EDV analysis

4. Pruning

5. Annotation of found sync

====Uses====
1. A tool to detect bad practices

2. Extensions to data race detection

====Accuracy====

====Related Work and similar tools====
There has been attempts to remove synchronization issues entirely from concurrent programming, such as transactional memory[[#Foot1|1]], a lock-free synchronization that does not require mutexes, and avoids having to use lock, unlock operations. Other attempts have been made to remove bugs that would otherwise be safe from data races but are are still at risk of unintended effects from thread interactions, such as Atomizer[[#Foot2|2]], a dynamic atomicity checker.

There are tools that detect data races such as CHESS[[#Foot3|3]], a dynamic data race checker that runs through all possible thread execution paths and CTrigger[[#Foot4|4]], a tool that checks for atomicity violations. The problem with these programs is that they only look for standard synchronization methods and structures, such as lock() and cond_wait(). They are not looking for ad hoc synchronizations.

A similar tool to SyncFinder exists that can detect simple spinning, also an ad hoc synchronization[[#Foot5|5]], but it only detects simple spinning and not the more complicated ad hoc variations.

Several studies on bug characteristics[[#Foot6|6]] and concurrency bugs[[#Foot7|7]] have been composed. This paper complements these studies to better understand the nature of ad hoc synchronizations and their occurrence in concurrent programs.

==Critique==
1. Uses static approach, dynamic would be better
* As stated in the paper, dynamic introduces run-time overhead and is not guaranteed to find if not executed in the test cases

2. not entirely accurate, some false positives.

3. In terms of style, lots of unnecessary repetition

==References==
1 M Herlihy and J.E.B. Moss, 2NA0. Transactional Memory:
Architectural Support for Lock-Free Data Structures. [online] Company(optional) Available at: <http://www.cs.brown.edu/~mph/HerlihyM93/herlihy93transactional.pdf> [Accessed 23 November 2010].

2 Author, 2010. Title. [online] Company(optional) Available at: <http://www.cs.williams.edu/~freund/papers/atomizer-padtad.pdf> [Accessed 23 November 2010].

3 Author, 2010. Title. [online] Company(optional) Available at: <http://research.microsoft.com/pubs/70509/tr-2007-149.pdf> [Accessed 23 November 2010].

4 Author, 2010. Title. [online] Company(optional) Available at: <http://pages.cs.wisc.edu/~shanlu/paper/asplos092-zhou.pdf> [Accessed 23 November 2010].

5 LI, T., LEBECK, A. R., AND SORIN, D. J. Spin detection hardware for improved management of multithreaded systems. IEEE Transactions on Parallel and Distributed Systems PDS-17, 6 (June 2006), 508–521.

6 Author, 2010. Title. [online] Company(optional) Available at: <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf> [Accessed 23 November 2010].

7 Author, 2010. Title. [online] Company(optional) Available at: <[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf]> [Accessed 23 November 2010].

8 Author, 2010. Title. [online] Company(optional) Available at: <[http://www.usenix.org/events/bsdcon/full_papers/baldwin/baldwin_html/node5.html]> [Accessed 23 November 2010].

9 Author, 2010. Title. [online] Company(optional) Available at: <http://homeostasis.scs.carleton.ca/wiki/index.php/Basic_Synchronization_Principles> [Accessed 23 November 2010].

Talk:COMP 3000 Essay 2 2010 Question 7

2010-11-15T16:00:26Z

Asoknack:

'''Attendence. Please mark your name to say you're here'''

Stephany Lay
--[[User:Asoknack|Asoknack]] 16:00, 15 November 2010 (UTC)

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-14T02:45:09Z

Asoknack: /* The Essay */

== Microkernel ==
* Moving kernel functionality into processes contained in user space, e.g. file systems, drivers
* Keep basic functionality in kernel to handle sharing of resources
* Separation allows for manageability and security, corruption in one does not necessarily cause failure in system
* Large amount of moving from a process to Kernel to user space and back again, this is a costly operation.

----

''' Microkernel '''
* try's to minimize the amount of software that is mandatory or required [7]
advantages of Microkernel
* favors a modular system structure [7]
* one failure of a program does not impact any other programs [7]
* can support more than one api or strategies since all programs are separated [7]
==== Microkernel Concepts ====
* piece of code is allowed in the kernel only if moving it outside the kernel would adversely affect the system. [7]
* any subsystem program created must be independent of all other subsystem's, any subsystem that is used can guarantee this from all other subsystems [7]
===== Address Space =====
* a mapping that relates the physical page to the virtual page. [7]
* processor specific [7]
* hide's the hardware's concept of address space [7]
* based off the idea of recursion each subsystem has it's own address space [7]
* the micro kernel provides 3 operations [7]
** Grant [7]
*** allows the owner to give a page to a recipient, provided the recipient want's it the page is removed from the owner's address space and but in the recipients. [7]
*** must be available to the owner. [7]
** Map [7]
*** allows the user to share a page with a recipient [7]
*** page is not removed from the owner's address space. [7]
** Flush [7]
*** remove's the page from all recipients address space [7]
*** how does this work with Grant --[[User:Asoknack|Asoknack]] 19:10, 12 October 2010 (UTC)
* allows memory management and paging out side the kernel
* Map and flush is required for memory manger's and pagers [7]
* can be used to implement access right's [7]
* controlling I/O Right's and driver's are not done at kernel level [7]

===== Thread's IPC =====
* Threads
** in the kernel [7]
** Since a thread has an address space , all changes to the thread need to be done by the kernel [7]
* IPC [7]
** in the kernel IPC
** grant and map also need IPC (So buye the priciple above this has to be in the kernel)[7]
** basic way for sub process to communicate. [7]
* Interrupts
** partially in the kernel [7]
** hard ware is a set of thread's which are empty except for there unique sender id [7]
** transformation of the message to the interrupt is done in the kernel [7]
** the kernel is not involved in device - specific interrupt's and does not understand the interrupt. [7]
*** resting the interrupt is done at user level [7]
** if a privileged command is need it is done implicitly the next time an IPC command is sent from the device [7]

===== Unique Identifiers =====

== Virtual Machine ==
* Partitioning or virtualizing resources among OS virtualization running on top of host OS
* Virtualized OS believe running on full machine on its own

----
System Level Virtualization

=== VMM ===
* stands for Virtual Machine Monitor, also known as the hyper-visor[4]
* responsible for virtualization of hardware(mapping physical to virtual) and the VM that run on top of the virtuallized hardware [4]
* usually a small os with no drivers , so it is coupled with a linux distro that provides device / hardware access [4]
** the os that the VMM is using for driver's is called the hostOS [6]
*the hostOS provides login and physical access to the hardware as well as management for the VMM [6]
=== VM ===
* the OS that the vm is running is called the guestOS [6]
* the guestOS only sees resources that have been allocated to the VM [6]
==== three approaches ====
*Type I virtualization [5]
** runs off the physical hardware [4]
** Isolation of the guestOs from the hardware is done threw processe level protection meachnism[6]
*** ring 0 = VMM [6]
*** ring 1 = VM [6]
*** this means all instructions from the VM must go threw the VMM [6]
** since there can be multiple VM's on a computer the scheduling is done by the VMM [6]
** on boot the VMM creates a hardware platform for the VM [6]
** load's the VM kernel into virtual memory and then boot's it like a regular computer [6]
** ex. Xen [4]
*Type II virtualization [5]
** run off the host Os [4]
** ex. VMware , QEMU [4]
* Para-virtualization [6]
** Similar to Type but use the HostOs for Device driver access [6]
** Provide a virtualization that is similar to hardware [From the paper posted, no citation yet]
** GuestOS and Hypervisor work together to improve performance

== Exokernel ==
* Micro-kernel architecture with limited abstractions, ask for resource, get resource not resource abstraction
* Less functionality provided by kernel, security and handling of resource sharing
* Once application receives resource, it can use it as it wishes/in control
* Keep the basic kernel to handle allocating resources and sharing rather than developing straight to the hardware

----
* multiplex resources securely providing protection to mutual distrustful application threw the use of secure binding's[1]
* Goal of the exokernel is to give LibOS maximum freedom with out allowing them to interfere with each other. to do this the exokernel separates protection from management in doing this it provide 3 important tasks[1]
** tracking ownership of resources [1]
** ensuring protection by guarding all resource usage and binding points (not to shure what binding points are)[1]
** revoking access to the resources [1]
* LibrayOS (LibOs)
** Reduces the number of kernel crossings[1]
** Not trusted by the exokernel so can be trusted by the application , Example given is a bad parameter passed to the LibOs only the application is affected.[1] (So LibOs cant interact with kernel ???)
** Any application running on the Exokernel can change the LibrayOs freely [1]
** Application that use LibOS that implement standard interfaces (POSIX) will be portable on any system with the same interface [1]
** LibOs can be made portable if it is designed to interact with a low-level machine independent level to hide hardware details [1]

=== Exokernel Design ===
==== Design Principles ====
*Securely Expose Hardware [1]
** an Exokernel tries to create low level primitives that the hardware resources can be accessed from, this also includes interrupts,exceptions [1]
** the exokernel also export privileged instructions to the LibOS so that traditional OS abstractions can be implemented (eg Process , address pace)[1]
** Exokernels should avoid resource management except when required protection ( allocation , revocation , ownership)[1]
** application based resource management is the best way to build flexible efficient flexible systems [1]
*Expose allocation[1]
** allow LibOs to request physical resources [1]
** resource allocation should not be automatic, the LibOS should participate in every single allocation decision [1]
*Expose Names[1]
** Use physical name's when ever possible[3] (not to sure what physical names are, I think it is as simple as what the hardware is called)--[[User:Asoknack|Asoknack]] 20:27, 9 October 2010 (UTC)
** Physical names capture useful information [3]
*** safer than and less resource intensive than virtual names as no translations are needed[3]
*Expose Revocation [1]
** use visible revocation protocol [1]
** allows well behaved LibOS to preform application level resource management [1]
** Visible revocation allows the LibOS to choose what instance of the resource to release[1](Visible means that when revocation happens the exokernel tell the LibOS that resource is being revoked)
''' Policy '''
* LibOS handle resource policy decisions
* Exokernels have a policy to decided between competing LibOS (Priority , share of resources)
** it enforces this threw allocation and deallocation (every thing can achieved threw this even what block to write and such)

==== Secure Bindings ====
* Used by the exokernel to allow the LibOS to bind to resources [1]
* Allows the separation of protection and resource use [1]
* only checks authorization during bind time [1]
** Application's with complex needs for resources only authorized during bind.[1]
* access checking is done during access time and there is no need to understand complex resources needs during access[1]
** (this means that the exokernel checks once to make sure an application has authorization once approved, when the application tries to use the resource the exokernel is only concerned about policy conflict's)--[[User:Asoknack|Asoknack]] 18:20, 9 October 2010 (UTC)
** allows the kernel to protect the resources with out understanding what the resource is [1]
*three way's to implement
* Hardware Mechanisms [1]
* Software caching [1]
* Downloading application code [1]
''' Downloading Code to the Kernel '''
* used to implement secure bindings , and improve performance[1]
** eliminate the number of kernel crossings [1]
** downloaded code can be run with out the application to be scheduled [2]
==== Visible Resource Revocation ====
* Used for most resources [1]
** allows for LibOS to help with deallocation [1]
** LibOS are able to garner what resources are scare [1]
* Slower than Invisible as application involvement is required [1]
** ex of when invisible is used is Processor addressing-context identifiers [1]
==== Abort Protocol ====
* allows the exokernel to take resources away from the LibOS [1]
* used when the LibOS fails to respond to the revocation request [1]
* Exokernel must be careful not to delete as the LibOS might need to write some system critical data to the resource [1]

== Comparisons ==
====Exokernel/Microkernel====
'''Similarities'''
* Limited functionality in kernel
** functionality in kernel to handle sharing of resources and security
** avoids programming directly to hardware which creates a dependency
* Additional functionality provided in user space as processes
'''Differences'''
* Minimal abstractions provided by the kernel
** Applications given more power in exokernel

====Exokernel/VM====
'''Similarities'''
* Idea of partitioning resources between applications/OSs
* "Control" of resource given
* Isolation from other applications/OSs
'''Differences'''
* Exokernel runs applications, VM runs OS
* VM uses a hostOS and guestOSs run on top
* Virtualization on VMs, Exokernel deals with real resources
* VM hides a lot of information because it emulates. Exokernel does not.

====Microkernel/VM====
'''Differences'''
* With a virtual machine, you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System.
* This can be costly but the benefits are that it's easier and all the standard OS features are available.

== References ==
[1]<nowiki> Engler, D. R., Kaashoek, M. F., and O'Toole, J. 1995. Exokernel: an operating system architecture for application-level resource management. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 251-266. DOI= http://doi.acm.org/10.1145/224056.224076 </nowiki>

[2]<nowiki>Engler, Dawson R. "The Exokernel Operating System Architecture." Diss. Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 1998. Web. 9 Oct. 2010. <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5054&rep=rep1&type=pdf>.</nowiki>

[3]<nowiki>Kaashoek, M. F., Engler, D. R., Ganger, G. R., Briceño, H. M., Hunt, R., Mazières, D., Pinckney, T., Grimm, R., Jannotti, J., and Mackenzie, K. 1997. Application performance and flexibility on exokernel systems. In Proceedings of the Sixteenth ACM Symposium on Operating Systems Principles (Saint Malo, France, October 05 - 08, 1997). W. M. Waite, Ed. SOSP '97. ACM, New York, NY, 52-65. DOI= http://doi.acm.org/10.1145/268998.266644 </nowiki>

[4]<nowiki>Vallee, G.; Naughton, T.; Engelmann, C.; Hong Ong; Scott, S.L.; , "System-Level Virtualization for High Performance Computing," Parallel, Distributed and Network-Based Processing, 2008. PDP 2008. 16th Euromicro Conference on , vol., no., pp.636-643, 13-15 Feb. 2008
DOI= http://doi.acm.org/10.1109/PDP.2008.85 </nowiki>

[5]<nowiki>Goldberg, R. P. 1973. Architecture of virtual machines. In Proceedings of the Workshop on Virtual Computer Systems (Cambridge, Massachusetts, United States, March 26 - 27, 1973). ACM, New York, NY, 74-112. DOI= http://doi.acm.org/10.1145/800122.803950 </nowiki>

[6]<nowiki>Vallee, G., Naughton, T., and Scott, S. L. 2007. System management software for virtual environments. In Proceedings of the 4th international Conference on Computing Frontiers (Ischia, Italy, May 07 - 09, 2007). CF '07. ACM, New York, NY, 153-160. DOI= http://doi.acm.org/10.1145/1242531.1242555 </nowiki>

[7]<nowiki>Liedtke, J. 1995. On micro-kernel construction. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 237-250. DOI= http://doi.acm.org/10.1145/224056.224075 </nowiki>

== Unsorted ==
An overview of exokernels,virtual machines, microkernels *[http://www2.supchurch.org:10999/files/school/classes/CSCI4730/Lectures/grad-structures.ppt Overview](Power Point) 
Should not be used as a source but an overview.

The original paper on [http://portal.acm.org/citation.cfm?id=224076 Exokernels] --[[User:Gautam|Gautam]] 22:39, 6 October 2010 (UTC)

Exokernel-
Minimalistic abstractions for developers
Exokernels can be seen as a good compromise between virtual machines and microkernels in the sense that exokernels can give that low level access to developers similar to direct access through a protected layer and at the same time can contain enough hardware abstraction to allow similar benefit of hiding the hardware resources to application programs.
Exokernel – fewest hardware abstractions to developer
Microkernel - is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system
Virtual machine is a simulation of any or devices requested by an application program
Exokenel – I’ve got a sound card
Virtual Machine – I’ve got the sound card you’re looking for, perfect virtual match
Microkernel – I’ve got sound card that plays Khazikstan sound format only
MicroKernel - Very small, very predictable, good for schedualing (QNX is a microkernel - POSIX compatable, benefits of running linux software like modern browsers)

This is some ideas I've got on this question, please contribute below
-Rovic

Outlining some main features here as I see them.

I found that the exokernel was an even lower-level design than the microkernel, closer to the hardware without abstraction. They have the same architecture with the basic functionality contained in the kernel to manage everyone. As the exokernel "gives" the resource to the application it can use the resource in isolation of other applications (until forced to shared) much like VMs receive their resources, either partitioned or virtualized, and execute as if its running on its own machine. There is this similar notion of partitioning the resources among applications/OS and allowing them to take control of what they have.

I'll locate some references later on. --[[User:Slay|Slay]] 15:00, 7 October 2010 (UTC)

I'm just going to post my answer for question 1 on the individuel assignment and hope it helps. --[[User:Aellebla|Aellebla]] 15:06, 12 October 2010 (UTC)

The design of the micro kernel was to take everything they could out of the Kernel and put it into a process. For ex, networking would be put into a process instead of staying in the kernel. The micro kernel dev's tried to keep lots of things in user space for efficiency. But one major problem with this is there would be a large amount of moving from a process to the kernel to user space and back again and this is a costly, non efficient process.It was an application specific OS, there was no multiplexing. With a virtual machine you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System. This is very heavy however but the benefits are that it‟s easy and all the standard OS features are there whereas in a microkernel setup they would not all be there and this can be seen as a compromise.

Exokernels can be seen as a compromise to virtual machines and microkernels because virtual machines emulate and exokernels do not. When you emulate something you hide a lot of the actual information because you wouldn‟t be able to see the „real‟ hardware. If we look at a virtual box setup running Linux, and we go look at all the hardware, it will be displayed as fake hardware.

Maybe we can have an introduction - paragraph or so on each type - then similarities - differences - and the compromise. I am going to do some research and writing this weekend and I will put some up -- Jslonosky

btw in my page (i guess you can call it that) i have some resources i have found --[[User:Asoknack|Asoknack]] 15:50, 8 October 2010 (UTC)
- Wow, nice man. I will go ahead and write up the descriptive paragraphs on each kernel and virtual machine if no one minds. --Jslonosky

I think we should divide up the paragraphs and proofread each others instead. (Are there only 4 of us?) I don't have much time to work on this today though but I'll try to work on it tomorrow morning. - Slay

Sure guy. That sounds good. There should be 5 or 6 of us though.. . Oh well. Their loss. I will do some before or after work today. Ill start with Microkernel since there is not a large amount of info here, and so we don't overlap each other - JSlonosky

yeah i think there was more like 7 of us btw if any one has any more information feel free to add it would be nice if you add the references so that way citing is really easy on acm.org it will auto give you the citation info (where it says Display Formats click on ACM Ref and new window with the citation info auto pop's up) --[[User:Asoknack|Asoknack]] 02:28, 11 October 2010 (UTC)

I added an outline of the similarities and differences. Add any more that I missed. These are from observations so I don't have any resources. -Slay
That's probably fine. Our textbook probably outlines some of them, so I am sure we can find a few there - JSlonosky

Talked to the teacher today and for VM he said we should focus on the implementation such as Xen and VMware , he also said to talk about para virtualization --[[User:Asoknack|Asoknack]] 18:42, 12 October 2010 (UTC)

A paper about emulation and paravirtualization [http://portal.acm.org/citation.cfm?id=1189289&coll=GUIDE&dl=GUIDE&CFID=105648137&CFTOKEN=47153176&ret=1#Fulltext link] - Slay

Oh no big words. Sorry about the Microkernels not done yet. Working on an outline now. Finally found how to access the ACM through carleton. Gawd.
I am planning an outline, quick bit about kernels in general, (maybe mention monolith kernels?), and what microkernels do.
I see the microkernel outline info and a reference ( Whomever did that == hero: true) about the scheduling and the Memory management. Should that be included in kernels in general and then mention what microkernels build upon/change? - JSlonosky

Sorry late to the party here. My mistake was not checking the discussion page when I checked in. I don't want to trample anyone's current work but I don't see any work on the final essay done. I would love to help just need to know where I can step in so as to not screw anyone else up. -- [[User:Cling|Cling]]

I don't think I'll be able to write up something for the final essay, even though I suggested splitting it. I'll do research tonight though on the paravirtualization. If I find the time, I'll try to write something. Sorry about that. --[[User:Slay|Slay]] 21:52, 13 October 2010 (UTC)

We all have 3004 to do too, man. I do not think anyone has chosen to do Virtual Machine section yet, or the Exokernel itself. But the contrast paragraph and the intro is chosen, and intro is done. Microkernel and kernel will be done in a hour I hope. -- JSlonosky

I can attempt to write up anything, the issue is I don't have any context on what to write, how do I tie it in to the rest of the essay? I only have a Japanese Quiz tomorrow morning then I should be good to write anything up for the rest of the day. As someone who has already written part of the essay, and assuming I attempt the exokernel section, how much do you think I should write? Should it just be about exokernel or should there be comparisons to the other topics? Thanks --[[User:Cling|Cling]] 23:14, 13 October 2010 (UTC)

Go with the Exokernel itself. Slade is getting off work in a hour and we can double check what he is doing then. We can put it together tomorrow sometime, and fill in the other stuff. - JSLonosky

I'll attempt to work on VM tonight, then. I would feel so bad if I didn't write anything. -Slay

Still wondering how much to write, I think we should decide on a decent word count or length so we don't have one short section (which would probably be mine) and/or one massive section that dwarfs all the others. If anyone has already written a section could you post your word count so we can aim to be around there, it would obviously be just a recommendation but it's just better to be on the safe side and have everything uniform. I haven't seen any formal requirements for the essay but I could be wrong, I also haven't been to class in a while. --[[User:Cling|Cling]] 23:33, 13 October 2010 (UTC)

Yeah Slay, VM probably doesnt have much to write about. Get something down, and we can go over it. CLing, Just write what you think. There is not a lot to go over if I write kernel/microkernel well enough. What is a exokernel? exokernel was an even lower-level design than the microkernel, closer to the hardware without abstraction, basically (As said by Slade). I will probably end up with 500 or a bit more words. -- JSlonosky

Sound off!

Who's actually reading this? Add your name to the list...

Rovic P.
Jon Slonosky
Corey Ling
Steph Lay

== The Essay ==

Let's actually breakdown the essay into components then write it here.

I'd like to go along the premise that microkernels and and virtual machines are "weaker" than exokernels in design for the essay. If anyone has any objections, add it here.

-Slade

what do you mean by "weaker"(i think you mean exokernels' takes the best of both worlds ) --[[User:Asoknack|Asoknack]] 02:45, 13 October 2010 (UTC)

What I mean by weaker is that we should focus on the things microkernels and virtual machines may not do as well compared to a system based off an exokernel design and then focus on how an exokenenel can take the best of both worlds. Please choose which section you will work on, that's not to say it'll be the only part you do, but rather we'll all contribute to each part please. 1 day left.
-Slade

...to the extent that exokernels be seen as a compromise between virtual machines and microkernels.
-I'll work on the initial intro. -Slade

3 paragraphs that prove it
Explain how the key design characteristics of these three system architectures compare with each other.

intro/thesis statement -Rovic P.

Paragraph 1 -Microkernel -Jon S.

Paragraph 2 -Virtual Machine -Steph L.

Paragraph 3 -Exokernel -Corey L

Paragraph 4 - Contrast/Compromise --[[User:Asoknack|Asoknack]]

Conclusion - Jon S. - Only a sentence per paragraph, excluding Intro

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-13T02:45:22Z

Asoknack: /* The Essay */

== Microkernel ==
* Moving kernel functionality into processes contained in user space, e.g. file systems, drivers
* Keep basic functionality in kernel to handle sharing of resources
* Separation allows for manageability and security, corruption in one does not necessarily cause failure in system
* Large amount of moving from a process to Kernel to user space and back again, this is a costly operation.

----

''' Microkernel '''
* try's to minimize the amount of software that is mandatory or required [7]
advantages of Microkernel
* favors a modular system structure [7]
* one failure of a program does not impact any other programs [7]
* can support more than one api or strategies since all programs are separated [7]
==== Microkernel Concepts ====
* piece of code is allowed in the kernel only if moving it outside the kernel would adversely affect the system. [7]
* any subsystem program created must be independent of all other subsystem's, any subsystem that is used can guarantee this from all other subsystems [7]
===== Address Space =====
* a mapping that relates the physical page to the virtual page. [7]
* processor specific [7]
* hide's the hardware's concept of address space [7]
* based off the idea of recursion each subsystem has it's own address space [7]
* the micro kernel provides 3 operations [7]
** Grant [7]
*** allows the owner to give a page to a recipient, provided the recipient want's it the page is removed from the owner's address space and but in the recipients. [7]
*** must be available to the owner. [7]
** Map [7]
*** allows the user to share a page with a recipient [7]
*** page is not removed from the owner's address space. [7]
** Flush [7]
*** remove's the page from all recipients address space [7]
*** how does this work with Grant --[[User:Asoknack|Asoknack]] 19:10, 12 October 2010 (UTC)
* allows memory management and paging out side the kernel
* Map and flush is required for memory manger's and pagers [7]
* can be used to implement access right's [7]
* controlling I/O Right's and driver's are not done at kernel level [7]

===== Thread's IPC =====
* Threads
** in the kernel [7]
** Since a thread has an address space , all changes to the thread need to be done by the kernel [7]
* IPC [7]
** in the kernel IPC
** grant and map also need IPC (So buye the priciple above this has to be in the kernel)[7]
** basic way for sub process to communicate. [7]
* Interrupts
** partially in the kernel [7]
** hard ware is a set of thread's which are empty except for there unique sender id [7]
** transformation of the message to the interrupt is done in the kernel [7]
** the kernel is not involved in device - specific interrupt's and does not understand the interrupt. [7]
*** resting the interrupt is done at user level [7]
** if a privileged command is need it is done implicitly the next time an IPC command is sent from the device [7]

===== Unique Identifiers =====

== Virtual Machine ==
* Partitioning or virtualizing resources among OS virtualization running on top of host OS
* Virtualized OS believe running on full machine on its own

----
System Level Virtualization

=== VMM ===
* stands for Virtual Machine Monitor, also known as the hyper-visor[4]
* responsible for virtualization of hardware(mapping physical to virtual) and the VM that run on top of the virtuallized hardware [4]
* usually a small os with no drivers , so it is coupled with a linux distro that provides device / hardware access [4]
** the os that the VMM is using for driver's is called the hostOS [6]
*the hostOS provides login and physical access to the hardware as well as management for the VMM [6]
=== VM ===
* the OS that the vm is running is called the guestOS [6]
* the guestOS only sees resources that have been allocated to the VM [6]
==== three approaches ====
*Type I virtualization [5]
** runs off the physical hardware [4]
** Isolation of the guestOs from the hardware is done threw processe level protection meachnism[6]
*** ring 0 = VMM [6]
*** ring 1 = VM [6]
*** this means all instructions from the VM must go threw the VMM [6]
** since there can be multiple VM's on a computer the scheduling is done by the VMM [6]
** on boot the VMM creates a hardware platform for the VM [6]
** load's the VM kernel into virtual memory and then boot's it like a regular computer [6]
** ex. Xen [4]
*Type II virtualization [5]
** run off the host Os [4]
** ex. VMware , QEMU [4]
* Para-virtualization [6]
** Similar to Type but use the HostOs for Device driver access [6]

== Exokernel ==
* Micro-kernel architecture with limited abstractions, ask for resource, get resource not resource abstraction
* Less functionality provided by kernel, security and handling of resource sharing
* Once application receives resource, it can use it as it wishes/in control
* Keep the basic kernel to handle allocating resources and sharing rather than developing straight to the hardware

----
* multiplex resources securely providing protection to mutual distrustful application threw the use of secure binding's[1]
* Goal of the exokernel is to give LibOS maximum freedom with out allowing them to interfere with each other. to do this the exokernel separates protection from management in doing this it provide 3 important tasks[1]
** tracking ownership of resources [1]
** ensuring protection by guarding all resource usage and binding points (not to shure what binding points are)[1]
** revoking access to the resources [1]
* LibrayOS (LibOs)
** Reduces the number of kernel crossings[1]
** Not trusted by the exokernel so can be trusted by the application , Example given is a bad parameter passed to the LibOs only the application is affected.[1] (So LibOs cant interact with kernel ???)
** Any application running on the Exokernel can change the LibrayOs freely [1]
** Application that use LibOS that implement standard interfaces (POSIX) will be portable on any system with the same interface [1]
** LibOs can be made portable if it is designed to interact with a low-level machine independent level to hide hardware details [1]

=== Exokernel Design ===
==== Design Principles ====
*Securely Expose Hardware [1]
** an Exokernel tries to create low level primitives that the hardware resources can be accessed from, this also includes interrupts,exceptions [1]
** the exokernel also export privileged instructions to the LibOS so that traditional OS abstractions can be implemented (eg Process , address pace)[1]
** Exokernels should avoid resource management except when required protection ( allocation , revocation , ownership)[1]
** application based resource management is the best way to build flexible efficient flexible systems [1]
*Expose allocation[1]
** allow LibOs to request physical resources [1]
** resource allocation should not be automatic, the LibOS should participate in every single allocation decision [1]
*Expose Names[1]
** Use physical name's when ever possible[3] (not to sure what physical names are, I think it is as simple as what the hardware is called)--[[User:Asoknack|Asoknack]] 20:27, 9 October 2010 (UTC)
** Physical names capture useful information [3]
*** safer than and less resource intensive than virtual names as no translations are needed[3]
*Expose Revocation [1]
** use visible revocation protocol [1]
** allows well behaved LibOS to preform application level resource management [1]
** Visible revocation allows the LibOS to choose what instance of the resource to release[1](Visible means that when revocation happens the exokernel tell the LibOS that resource is being revoked)
''' Policy '''
* LibOS handle resource policy decisions
* Exokernels have a policy to decided between competing LibOS (Priority , share of resources)
** it enforces this threw allocation and deallocation (every thing can achieved threw this even what block to write and such)

==== Secure Bindings ====
* Used by the exokernel to allow the LibOS to bind to resources [1]
* Allows the separation of protection and resource use [1]
* only checks authorization during bind time [1]
** Application's with complex needs for resources only authorized during bind.[1]
* access checking is done during access time and there is no need to understand complex resources needs during access[1]
** (this means that the exokernel checks once to make sure an application has authorization once approved, when the application tries to use the resource the exokernel is only concerned about policy conflict's)--[[User:Asoknack|Asoknack]] 18:20, 9 October 2010 (UTC)
** allows the kernel to protect the resources with out understanding what the resource is [1]
*three way's to implement
* Hardware Mechanisms [1]
* Software caching [1]
* Downloading application code [1]
''' Downloading Code to the Kernel '''
* used to implement secure bindings , and improve performance[1]
** eliminate the number of kernel crossings [1]
** downloaded code can be run with out the application to be scheduled [2]
==== Visible Resource Revocation ====
* Used for most resources [1]
** allows for LibOS to help with deallocation [1]
** LibOS are able to garner what resources are scare [1]
* Slower than Invisible as application involvement is required [1]
** ex of when invisible is used is Processor addressing-context identifiers [1]
==== Abort Protocol ====
* allows the exokernel to take resources away from the LibOS [1]
* used when the LibOS fails to respond to the revocation request [1]
* Exokernel must be careful not to delete as the LibOS might need to write some system critical data to the resource [1]

== Comparisons ==
====Exokernel/Microkernel====
'''Similarities'''
* Limited functionality in kernel
** functionality in kernel to handle sharing of resources and security
** avoids programming directly to hardware which creates a dependency
* Additional functionality provided in user space as processes
'''Differences'''
* Minimal abstractions provided by the kernel
** Applications given more power in exokernel

====Exokernel/VM====
'''Similarities'''
* Idea of partitioning resources between applications/OSs
* "Control" of resource given
* Isolation from other applications/OSs
'''Differences'''
* Exokernel runs applications, VM runs OS
* VM uses a hostOS and guestOSs run on top
* Virtualization on VMs, Exokernel deals with real resources
* VM hides a lot of information because it emulates. Exokernel does not.

====Microkernel/VM====
'''Differences'''
* With a virtual machine, you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System.
* This can be costly but the benefits are that it's easier and all the standard OS features are available.

== References ==
[1]<nowiki> Engler, D. R., Kaashoek, M. F., and O'Toole, J. 1995. Exokernel: an operating system architecture for application-level resource management. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 251-266. DOI= http://doi.acm.org/10.1145/224056.224076 </nowiki>

[2]<nowiki>Engler, Dawson R. "The Exokernel Operating System Architecture." Diss. Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 1998. Web. 9 Oct. 2010. <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5054&rep=rep1&type=pdf>.</nowiki>

[3]<nowiki>Kaashoek, M. F., Engler, D. R., Ganger, G. R., Briceño, H. M., Hunt, R., Mazières, D., Pinckney, T., Grimm, R., Jannotti, J., and Mackenzie, K. 1997. Application performance and flexibility on exokernel systems. In Proceedings of the Sixteenth ACM Symposium on Operating Systems Principles (Saint Malo, France, October 05 - 08, 1997). W. M. Waite, Ed. SOSP '97. ACM, New York, NY, 52-65. DOI= http://doi.acm.org/10.1145/268998.266644 </nowiki>

[4]<nowiki>Vallee, G.; Naughton, T.; Engelmann, C.; Hong Ong; Scott, S.L.; , "System-Level Virtualization for High Performance Computing," Parallel, Distributed and Network-Based Processing, 2008. PDP 2008. 16th Euromicro Conference on , vol., no., pp.636-643, 13-15 Feb. 2008
DOI= http://doi.acm.org/10.1109/PDP.2008.85 </nowiki>

[5]<nowiki>Goldberg, R. P. 1973. Architecture of virtual machines. In Proceedings of the Workshop on Virtual Computer Systems (Cambridge, Massachusetts, United States, March 26 - 27, 1973). ACM, New York, NY, 74-112. DOI= http://doi.acm.org/10.1145/800122.803950 </nowiki>

[6]<nowiki>Vallee, G., Naughton, T., and Scott, S. L. 2007. System management software for virtual environments. In Proceedings of the 4th international Conference on Computing Frontiers (Ischia, Italy, May 07 - 09, 2007). CF '07. ACM, New York, NY, 153-160. DOI= http://doi.acm.org/10.1145/1242531.1242555 </nowiki>

[7]<nowiki>Liedtke, J. 1995. On micro-kernel construction. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 237-250. DOI= http://doi.acm.org/10.1145/224056.224075 </nowiki>

== Unsorted ==
An overview of exokernels,virtual machines, microkernels *[http://www2.supchurch.org:10999/files/school/classes/CSCI4730/Lectures/grad-structures.ppt Overview](Power Point) 
Should not be used as a source but an overview.

The original paper on [http://portal.acm.org/citation.cfm?id=224076 Exokernels] --[[User:Gautam|Gautam]] 22:39, 6 October 2010 (UTC)

Exokernel-
Minimalistic abstractions for developers
Exokernels can be seen as a good compromise between virtual machines and microkernels in the sense that exokernels can give that low level access to developers similar to direct access through a protected layer and at the same time can contain enough hardware abstraction to allow similar benefit of hiding the hardware resources to application programs.
Exokernel – fewest hardware abstractions to developer
Microkernel - is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system
Virtual machine is a simulation of any or devices requested by an application program
Exokenel – I’ve got a sound card
Virtual Machine – I’ve got the sound card you’re looking for, perfect virtual match
Microkernel – I’ve got sound card that plays Khazikstan sound format only
MicroKernel - Very small, very predictable, good for schedualing (QNX is a microkernel - POSIX compatable, benefits of running linux software like modern browsers)

This is some ideas I've got on this question, please contribute below
-Rovic

Outlining some main features here as I see them.

I found that the exokernel was an even lower-level design than the microkernel, closer to the hardware without abstraction. They have the same architecture with the basic functionality contained in the kernel to manage everyone. As the exokernel "gives" the resource to the application it can use the resource in isolation of other applications (until forced to shared) much like VMs receive their resources, either partitioned or virtualized, and execute as if its running on its own machine. There is this similar notion of partitioning the resources among applications/OS and allowing them to take control of what they have.

I'll locate some references later on. --[[User:Slay|Slay]] 15:00, 7 October 2010 (UTC)

I'm just going to post my answer for question 1 on the individuel assignment and hope it helps. --[[User:Aellebla|Aellebla]] 15:06, 12 October 2010 (UTC)

The design of the micro kernel was to take everything they could out of the Kernel and put it into a process. For ex, networking would be put into a process instead of staying in the kernel. The micro kernel dev's tried to keep lots of things in user space for efficiency. But one major problem with this is there would be a large amount of moving from a process to the kernel to user space and back again and this is a costly, non efficient process.It was an application specific OS, there was no multiplexing. With a virtual machine you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System. This is very heavy however but the benefits are that it‟s easy and all the standard OS features are there whereas in a microkernel setup they would not all be there and this can be seen as a compromise.

Exokernels can be seen as a compromise to virtual machines and microkernels because virtual machines emulate and exokernels do not. When you emulate something you hide a lot of the actual information because you wouldn‟t be able to see the „real‟ hardware. If we look at a virtual box setup running Linux, and we go look at all the hardware, it will be displayed as fake hardware.

Maybe we can have an introduction - paragraph or so on each type - then similarities - differences - and the compromise. I am going to do some research and writing this weekend and I will put some up -- Jslonosky

btw in my page (i guess you can call it that) i have some resources i have found --[[User:Asoknack|Asoknack]] 15:50, 8 October 2010 (UTC)
- Wow, nice man. I will go ahead and write up the descriptive paragraphs on each kernel and virtual machine if no one minds. --Jslonosky

I think we should divide up the paragraphs and proofread each others instead. (Are there only 4 of us?) I don't have much time to work on this today though but I'll try to work on it tomorrow morning. - Slay

Sure guy. That sounds good. There should be 5 or 6 of us though.. . Oh well. Their loss. I will do some before or after work today. Ill start with Microkernel since there is not a large amount of info here, and so we don't overlap each other - JSlonosky

yeah i think there was more like 7 of us btw if any one has any more information feel free to add it would be nice if you add the references so that way citing is really easy on acm.org it will auto give you the citation info (where it says Display Formats click on ACM Ref and new window with the citation info auto pop's up) --[[User:Asoknack|Asoknack]] 02:28, 11 October 2010 (UTC)

I added an outline of the similarities and differences. Add any more that I missed. These are from observations so I don't have any resources. -Slay
That's probably fine. Our textbook probably outlines some of them, so I am sure we can find a few there - JSlonosky

Talked to the teacher today and for VM he said we should focus on the implementation such as Xen and VMware , he also said to talk about para virtualization --[[User:Asoknack|Asoknack]] 18:42, 12 October 2010 (UTC)

== The Essay ==

Let's actually breakdown the essay into components then write it here.

I'd like to go along the premise that microkernels and and virtual machines are "weaker" than exokernels in design for the essay. If anyone has any objections, add it here.

-Slade

what do you mean by "weaker"(i think you mean exokernels' takes the best of both worlds ) --[[User:Asoknack|Asoknack]] 02:45, 13 October 2010 (UTC)

We have our intro/thesis statement

...to the extent that exokernels be seen as a compromise between virtual machines and microkernels.
-I'll work on the initial intro, should have it ready by tonight. -Slade

3 paragraphs that prove it
Explain how the key design characteristics of these three system architectures compare with each other.

and conclusion

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-12T19:39:48Z

Asoknack: /* Address Space */

== Microkernel ==
* Moving kernel functionality into processes contained in user space, e.g. file systems, drivers
* Keep basic functionality in kernel to handle sharing of resources
* Separation allows for manageability and security, corruption in one does not necessarily cause failure in system
* Large amount of moving from a process to Kernel to user space and back again, this is a costly operation.

----

''' Microkernel '''
* try's to minimize the amount of software that is mandatory or required [7]
advantages of Microkernel
* favors a modular system structure [7]
* one failure of a program does not impact any other programs [7]
* can support more than one api or strategies since all programs are separated [7]
==== Microkernel Concepts ====
* piece of code is allowed in the kernel only if moving it outside the kernel would adversely affect the system. [7]
* any subsystem program created must be independent of all other subsystem's, any subsystem that is used can guarantee this from all other subsystems [7]
===== Address Space =====
* a mapping that relates the physical page to the virtual page. [7]
* processor specific [7]
* hide's the hardware's concept of address space [7]
* based off the idea of recursion each subsystem has it's own address space [7]
* the micro kernel provides 3 operations [7]
** Grant [7]
*** allows the owner to give a page to a recipient, provided the recipient want's it the page is removed from the owner's address space and but in the recipients. [7]
*** must be available to the owner. [7]
** Map [7]
*** allows the user to share a page with a recipient [7]
*** page is not removed from the owner's address space. [7]
** Flush [7]
*** remove's the page from all recipients address space [7]
*** how does this work with Grant --[[User:Asoknack|Asoknack]] 19:10, 12 October 2010 (UTC)
* allows memory management and paging out side the kernel
* Map and flush is required for memory manger's and pagers [7]
* can be used to implement access right's [7]
* controlling I/O Right's and driver's are not done at kernel level [7]

===== Thread's IPC =====
* Threads
** in the kernel [7]
** Since a thread has an address space , all changes to the thread need to be done by the kernel [7]
* IPC [7]
** in the kernel IPC
** grant and map also need IPC (So buye the priciple above this has to be in the kernel)[7]
** basic way for sub process to communicate. [7]
* Interrupts
** partially in the kernel [7]
** hard ware is a set of thread's which are empty except for there unique sender id [7]
** transformation of the message to the interrupt is done in the kernel [7]
** the kernel is not involved in device - specific interrupt's and does not understand the interrupt. [7]
*** resting the interrupt is done at user level [7]
** if a privileged command is need it is done implicitly the next time an IPC command is sent from the device [7]

===== Unique Identifiers =====

== Virtual Machine ==
* Partitioning or virtualizing resources among OS virtualization running on top of host OS
* Virtualized OS believe running on full machine on its own

----
System Level Virtualization

=== VMM ===
* stands for Virtual Machine Monitor, also known as the hyper-visor[4]
* responsible for virtualization of hardware(mapping physical to virtual) and the VM that run on top of the virtuallized hardware [4]
* usually a small os with no drivers , so it is coupled with a linux distro that provides device / hardware access [4]
** the os that the VMM is using for driver's is called the hostOS [6]
*the hostOS provides login and physical access to the hardware as well as management for the VMM [6]
=== VM ===
* the OS that the vm is running is called the guestOS [6]
* the guestOS only sees resources that have been allocated to the VM [6]
==== three approaches ====
*Type I virtualization [5]
** runs off the physical hardware [4]
** Isolation of the guestOs from the hardware is done threw processe level protection meachnism[6]
*** ring 0 = VMM [6]
*** ring 1 = VM [6]
*** this means all instructions from the VM must go threw the VMM [6]
** since there can be multiple VM's on a computer the scheduling is done by the VMM [6]
** on boot the VMM creates a hardware platform for the VM [6]
** load's the VM kernel into virtual memory and then boot's it like a regular computer [6]
** ex. Xen [4]
*Type II virtualization [5]
** run off the host Os [4]
** ex. VMware , QEMU [4]
* Para-virtualization [6]
** Similar to Type but use the HostOs for Device driver access [6]

== Exokernel ==
* Micro-kernel architecture with limited abstractions, ask for resource, get resource not resource abstraction
* Less functionality provided by kernel, security and handling of resource sharing
* Once application receives resource, it can use it as it wishes/in control
* Keep the basic kernel to handle allocating resources and sharing rather than developing straight to the hardware

----
* multiplex resources securely providing protection to mutual distrustful application threw the use of secure binding's[1]
* Goal of the exokernel is to give LibOS maximum freedom with out allowing them to interfere with each other. to do this the exokernel separates protection from management in doing this it provide 3 important tasks[1]
** tracking ownership of resources [1]
** ensuring protection by guarding all resource usage and binding points (not to shure what binding points are)[1]
** revoking access to the resources [1]
* LibrayOS (LibOs)
** Reduces the number of kernel crossings[1]
** Not trusted by the exokernel so can be trusted by the application , Example given is a bad parameter passed to the LibOs only the application is affected.[1] (So LibOs cant interact with kernel ???)
** Any application running on the Exokernel can change the LibrayOs freely [1]
** Application that use LibOS that implement standard interfaces (POSIX) will be portable on any system with the same interface [1]
** LibOs can be made portable if it is designed to interact with a low-level machine independent level to hide hardware details [1]

=== Exokernel Design ===
==== Design Principles ====
*Securely Expose Hardware [1]
** an Exokernel tries to create low level primitives that the hardware resources can be accessed from, this also includes interrupts,exceptions [1]
** the exokernel also export privileged instructions to the LibOS so that traditional OS abstractions can be implemented (eg Process , address pace)[1]
** Exokernels should avoid resource management except when required protection ( allocation , revocation , ownership)[1]
** application based resource management is the best way to build flexible efficient flexible systems [1]
*Expose allocation[1]
** allow LibOs to request physical resources [1]
** resource allocation should not be automatic, the LibOS should participate in every single allocation decision [1]
*Expose Names[1]
** Use physical name's when ever possible[3] (not to sure what physical names are, I think it is as simple as what the hardware is called)--[[User:Asoknack|Asoknack]] 20:27, 9 October 2010 (UTC)
** Physical names capture useful information [3]
*** safer than and less resource intensive than virtual names as no translations are needed[3]
*Expose Revocation [1]
** use visible revocation protocol [1]
** allows well behaved LibOS to preform application level resource management [1]
** Visible revocation allows the LibOS to choose what instance of the resource to release[1](Visible means that when revocation happens the exokernel tell the LibOS that resource is being revoked)
''' Policy '''
* LibOS handle resource policy decisions
* Exokernels have a policy to decided between competing LibOS (Priority , share of resources)
** it enforces this threw allocation and deallocation (every thing can achieved threw this even what block to write and such)

==== Secure Bindings ====
* Used by the exokernel to allow the LibOS to bind to resources [1]
* Allows the separation of protection and resource use [1]
* only checks authorization during bind time [1]
** Application's with complex needs for resources only authorized during bind.[1]
* access checking is done during access time and there is no need to understand complex resources needs during access[1]
** (this means that the exokernel checks once to make sure an application has authorization once approved, when the application tries to use the resource the exokernel is only concerned about policy conflict's)--[[User:Asoknack|Asoknack]] 18:20, 9 October 2010 (UTC)
** allows the kernel to protect the resources with out understanding what the resource is [1]
*three way's to implement
* Hardware Mechanisms [1]
* Software caching [1]
* Downloading application code [1]
''' Downloading Code to the Kernel '''
* used to implement secure bindings , and improve performance[1]
** eliminate the number of kernel crossings [1]
** downloaded code can be run with out the application to be scheduled [2]
==== Visible Resource Revocation ====
* Used for most resources [1]
** allows for LibOS to help with deallocation [1]
** LibOS are able to garner what resources are scare [1]
* Slower than Invisible as application involvement is required [1]
** ex of when invisible is used is Processor addressing-context identifiers [1]
==== Abort Protocol ====
* allows the exokernel to take resources away from the LibOS [1]
* used when the LibOS fails to respond to the revocation request [1]
* Exokernel must be careful not to delete as the LibOS might need to write some system critical data to the resource [1]

== Comparisons ==
====Exokernel/Microkernel====
'''Similarities'''
* Limited functionality in kernel
** functionality in kernel to handle sharing of resources and security
** avoids programming directly to hardware which creates a dependency
* Additional functionality provided in user space as processes
'''Differences'''
* Minimal abstractions provided by the kernel
** Applications given more power in exokernel

====Exokernel/VM====
'''Similarities'''
* Idea of partitioning resources between applications/OSs
* "Control" of resource given
* Isolation from other applications/OSs
'''Differences'''
* Exokernel runs applications, VM runs OS
* VM uses a hostOS and guestOSs run on top
* Virtualization on VMs, Exokernel deals with real resources
* VM hides a lot of information because it emulates. Exokernel does not.

====Microkernel/VM====
'''Differences'''
* With a virtual machine, you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System.
* This can be costly but the benefits are that it's easier and all the standard OS features are available.

== References ==
[1]<nowiki> Engler, D. R., Kaashoek, M. F., and O'Toole, J. 1995. Exokernel: an operating system architecture for application-level resource management. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 251-266. DOI= http://doi.acm.org/10.1145/224056.224076 </nowiki>

[2]<nowiki>Engler, Dawson R. "The Exokernel Operating System Architecture." Diss. Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 1998. Web. 9 Oct. 2010. <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5054&rep=rep1&type=pdf>.</nowiki>

[3]<nowiki>Kaashoek, M. F., Engler, D. R., Ganger, G. R., Briceño, H. M., Hunt, R., Mazières, D., Pinckney, T., Grimm, R., Jannotti, J., and Mackenzie, K. 1997. Application performance and flexibility on exokernel systems. In Proceedings of the Sixteenth ACM Symposium on Operating Systems Principles (Saint Malo, France, October 05 - 08, 1997). W. M. Waite, Ed. SOSP '97. ACM, New York, NY, 52-65. DOI= http://doi.acm.org/10.1145/268998.266644 </nowiki>

[4]<nowiki>Vallee, G.; Naughton, T.; Engelmann, C.; Hong Ong; Scott, S.L.; , "System-Level Virtualization for High Performance Computing," Parallel, Distributed and Network-Based Processing, 2008. PDP 2008. 16th Euromicro Conference on , vol., no., pp.636-643, 13-15 Feb. 2008
DOI= http://doi.acm.org/10.1109/PDP.2008.85 </nowiki>

[5]<nowiki>Goldberg, R. P. 1973. Architecture of virtual machines. In Proceedings of the Workshop on Virtual Computer Systems (Cambridge, Massachusetts, United States, March 26 - 27, 1973). ACM, New York, NY, 74-112. DOI= http://doi.acm.org/10.1145/800122.803950 </nowiki>

[6]<nowiki>Vallee, G., Naughton, T., and Scott, S. L. 2007. System management software for virtual environments. In Proceedings of the 4th international Conference on Computing Frontiers (Ischia, Italy, May 07 - 09, 2007). CF '07. ACM, New York, NY, 153-160. DOI= http://doi.acm.org/10.1145/1242531.1242555 </nowiki>

[7]<nowiki>Liedtke, J. 1995. On micro-kernel construction. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 237-250. DOI= http://doi.acm.org/10.1145/224056.224075 </nowiki>

== Unsorted ==
An overview of exokernels,virtual machines, microkernels *[http://www2.supchurch.org:10999/files/school/classes/CSCI4730/Lectures/grad-structures.ppt Overview](Power Point) 
Should not be used as a source but an overview.

The original paper on [http://portal.acm.org/citation.cfm?id=224076 Exokernels] --[[User:Gautam|Gautam]] 22:39, 6 October 2010 (UTC)

Exokernel-
Minimalistic abstractions for developers
Exokernels can be seen as a good compromise between virtual machines and microkernels in the sense that exokernels can give that low level access to developers similar to direct access through a protected layer and at the same time can contain enough hardware abstraction to allow similar benefit of hiding the hardware resources to application programs.
Exokernel – fewest hardware abstractions to developer
Microkernel - is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system
Virtual machine is a simulation of any or devices requested by an application program
Exokenel – I’ve got a sound card
Virtual Machine – I’ve got the sound card you’re looking for, perfect virtual match
Microkernel – I’ve got sound card that plays Khazikstan sound format only
MicroKernel - Very small, very predictable, good for schedualing (QNX is a microkernel - POSIX compatable, benefits of running linux software like modern browsers)

This is some ideas I've got on this question, please contribute below
-Rovic

Outlining some main features here as I see them.

I found that the exokernel was an even lower-level design than the microkernel, closer to the hardware without abstraction. They have the same architecture with the basic functionality contained in the kernel to manage everyone. As the exokernel "gives" the resource to the application it can use the resource in isolation of other applications (until forced to shared) much like VMs receive their resources, either partitioned or virtualized, and execute as if its running on its own machine. There is this similar notion of partitioning the resources among applications/OS and allowing them to take control of what they have.

I'll locate some references later on. --[[User:Slay|Slay]] 15:00, 7 October 2010 (UTC)

I'm just going to post my answer for question 1 on the individuel assignment and hope it helps. --[[User:Aellebla|Aellebla]] 15:06, 12 October 2010 (UTC)

The design of the micro kernel was to take everything they could out of the Kernel and put it into a process. For ex, networking would be put into a process instead of staying in the kernel. The micro kernel dev's tried to keep lots of things in user space for efficiency. But one major problem with this is there would be a large amount of moving from a process to the kernel to user space and back again and this is a costly, non efficient process.It was an application specific OS, there was no multiplexing. With a virtual machine you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System. This is very heavy however but the benefits are that it‟s easy and all the standard OS features are there whereas in a microkernel setup they would not all be there and this can be seen as a compromise.

Exokernels can be seen as a compromise to virtual machines and microkernels because virtual machines emulate and exokernels do not. When you emulate something you hide a lot of the actual information because you wouldn‟t be able to see the „real‟ hardware. If we look at a virtual box setup running Linux, and we go look at all the hardware, it will be displayed as fake hardware.

Maybe we can have an introduction - paragraph or so on each type - then similarities - differences - and the compromise. I am going to do some research and writing this weekend and I will put some up -- Jslonosky

btw in my page (i guess you can call it that) i have some resources i have found --[[User:Asoknack|Asoknack]] 15:50, 8 October 2010 (UTC)
- Wow, nice man. I will go ahead and write up the descriptive paragraphs on each kernel and virtual machine if no one minds. --Jslonosky

I think we should divide up the paragraphs and proofread each others instead. (Are there only 4 of us?) I don't have much time to work on this today though but I'll try to work on it tomorrow morning. - Slay

Sure guy. That sounds good. There should be 5 or 6 of us though.. . Oh well. Their loss. I will do some before or after work today. Ill start with Microkernel since there is not a large amount of info here, and so we don't overlap each other - JSlonosky

yeah i think there was more like 7 of us btw if any one has any more information feel free to add it would be nice if you add the references so that way citing is really easy on acm.org it will auto give you the citation info (where it says Display Formats click on ACM Ref and new window with the citation info auto pop's up) --[[User:Asoknack|Asoknack]] 02:28, 11 October 2010 (UTC)

I added an outline of the similarities and differences. Add any more that I missed. These are from observations so I don't have any resources. -Slay
That's probably fine. Our textbook probably outlines some of them, so I am sure we can find a few there - JSlonosky

Talked to the teacher today and for VM he said we should focus on the implementation such as Xen and VMware , he also said to talk about para virtualization --[[User:Asoknack|Asoknack]] 18:42, 12 October 2010 (UTC)

== The Essay ==

Let's actually breakdown the essay into components then write it here.

We have our intro/thesis statement

...to the extent that exokernels be seen as a compromise between virtual machines and microkernels.
-I'll work on the initial intro, should have it ready by tonight. -Slade

3 paragraphs that prove it
Explain how the key design characteristics of these three system architectures compare with each other.

and conclusion

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-12T19:38:16Z

Asoknack: /* Thread's IPC */

== Microkernel ==
* Moving kernel functionality into processes contained in user space, e.g. file systems, drivers
* Keep basic functionality in kernel to handle sharing of resources
* Separation allows for manageability and security, corruption in one does not necessarily cause failure in system
* Large amount of moving from a process to Kernel to user space and back again, this is a costly operation.

----

''' Microkernel '''
* try's to minimize the amount of software that is mandatory or required [7]
advantages of Microkernel
* favors a modular system structure [7]
* one failure of a program does not impact any other programs [7]
* can support more than one api or strategies since all programs are separated [7]
==== Microkernel Concepts ====
* piece of code is allowed in the kernel only if moving it outside the kernel would adversely affect the system. [7]
* any subsystem program created must be independent of all other subsystem's, any subsystem that is used can guarantee this from all other subsystems [7]
===== Address Space =====
* a mapping that relates the physical page to the virtual page. [7]
* hide's the hardware's concept of address space [7]
* based off the idea of recursion each subsystem has it's own address space [7]
* the micro kernel provides 3 operations [7]
** Grant [7]
*** allows the owner to give a page to a recipient, provided the recipient want's it the page is removed from the owner's address space and but in the recipients. [7]
*** must be available to the owner. [7]
** Map [7]
*** allows the user to share a page with a recipient [7]
*** page is not removed from the owner's address space. [7]
** Flush [7]
*** remove's the page from all recipients address space [7]
*** how does this work with Grant --[[User:Asoknack|Asoknack]] 19:10, 12 October 2010 (UTC)
* allows memory management and paging out side the kernel
* Map and flush is required for memory manger's and pagers [7]
* can be used to implement access right's [7]
* controlling I/O Right's and driver's are not done at kernel level [7]

===== Thread's IPC =====
* Threads
** in the kernel [7]
** Since a thread has an address space , all changes to the thread need to be done by the kernel [7]
* IPC [7]
** in the kernel IPC
** grant and map also need IPC (So buye the priciple above this has to be in the kernel)[7]
** basic way for sub process to communicate. [7]
* Interrupts
** partially in the kernel [7]
** hard ware is a set of thread's which are empty except for there unique sender id [7]
** transformation of the message to the interrupt is done in the kernel [7]
** the kernel is not involved in device - specific interrupt's and does not understand the interrupt. [7]
*** resting the interrupt is done at user level [7]
** if a privileged command is need it is done implicitly the next time an IPC command is sent from the device [7]

===== Unique Identifiers =====

== Virtual Machine ==
* Partitioning or virtualizing resources among OS virtualization running on top of host OS
* Virtualized OS believe running on full machine on its own

----
System Level Virtualization

=== VMM ===
* stands for Virtual Machine Monitor, also known as the hyper-visor[4]
* responsible for virtualization of hardware(mapping physical to virtual) and the VM that run on top of the virtuallized hardware [4]
* usually a small os with no drivers , so it is coupled with a linux distro that provides device / hardware access [4]
** the os that the VMM is using for driver's is called the hostOS [6]
*the hostOS provides login and physical access to the hardware as well as management for the VMM [6]
=== VM ===
* the OS that the vm is running is called the guestOS [6]
* the guestOS only sees resources that have been allocated to the VM [6]
==== three approaches ====
*Type I virtualization [5]
** runs off the physical hardware [4]
** Isolation of the guestOs from the hardware is done threw processe level protection meachnism[6]
*** ring 0 = VMM [6]
*** ring 1 = VM [6]
*** this means all instructions from the VM must go threw the VMM [6]
** since there can be multiple VM's on a computer the scheduling is done by the VMM [6]
** on boot the VMM creates a hardware platform for the VM [6]
** load's the VM kernel into virtual memory and then boot's it like a regular computer [6]
** ex. Xen [4]
*Type II virtualization [5]
** run off the host Os [4]
** ex. VMware , QEMU [4]
* Para-virtualization [6]
** Similar to Type but use the HostOs for Device driver access [6]

== Exokernel ==
* Micro-kernel architecture with limited abstractions, ask for resource, get resource not resource abstraction
* Less functionality provided by kernel, security and handling of resource sharing
* Once application receives resource, it can use it as it wishes/in control
* Keep the basic kernel to handle allocating resources and sharing rather than developing straight to the hardware

----
* multiplex resources securely providing protection to mutual distrustful application threw the use of secure binding's[1]
* Goal of the exokernel is to give LibOS maximum freedom with out allowing them to interfere with each other. to do this the exokernel separates protection from management in doing this it provide 3 important tasks[1]
** tracking ownership of resources [1]
** ensuring protection by guarding all resource usage and binding points (not to shure what binding points are)[1]
** revoking access to the resources [1]
* LibrayOS (LibOs)
** Reduces the number of kernel crossings[1]
** Not trusted by the exokernel so can be trusted by the application , Example given is a bad parameter passed to the LibOs only the application is affected.[1] (So LibOs cant interact with kernel ???)
** Any application running on the Exokernel can change the LibrayOs freely [1]
** Application that use LibOS that implement standard interfaces (POSIX) will be portable on any system with the same interface [1]
** LibOs can be made portable if it is designed to interact with a low-level machine independent level to hide hardware details [1]

=== Exokernel Design ===
==== Design Principles ====
*Securely Expose Hardware [1]
** an Exokernel tries to create low level primitives that the hardware resources can be accessed from, this also includes interrupts,exceptions [1]
** the exokernel also export privileged instructions to the LibOS so that traditional OS abstractions can be implemented (eg Process , address pace)[1]
** Exokernels should avoid resource management except when required protection ( allocation , revocation , ownership)[1]
** application based resource management is the best way to build flexible efficient flexible systems [1]
*Expose allocation[1]
** allow LibOs to request physical resources [1]
** resource allocation should not be automatic, the LibOS should participate in every single allocation decision [1]
*Expose Names[1]
** Use physical name's when ever possible[3] (not to sure what physical names are, I think it is as simple as what the hardware is called)--[[User:Asoknack|Asoknack]] 20:27, 9 October 2010 (UTC)
** Physical names capture useful information [3]
*** safer than and less resource intensive than virtual names as no translations are needed[3]
*Expose Revocation [1]
** use visible revocation protocol [1]
** allows well behaved LibOS to preform application level resource management [1]
** Visible revocation allows the LibOS to choose what instance of the resource to release[1](Visible means that when revocation happens the exokernel tell the LibOS that resource is being revoked)
''' Policy '''
* LibOS handle resource policy decisions
* Exokernels have a policy to decided between competing LibOS (Priority , share of resources)
** it enforces this threw allocation and deallocation (every thing can achieved threw this even what block to write and such)

==== Secure Bindings ====
* Used by the exokernel to allow the LibOS to bind to resources [1]
* Allows the separation of protection and resource use [1]
* only checks authorization during bind time [1]
** Application's with complex needs for resources only authorized during bind.[1]
* access checking is done during access time and there is no need to understand complex resources needs during access[1]
** (this means that the exokernel checks once to make sure an application has authorization once approved, when the application tries to use the resource the exokernel is only concerned about policy conflict's)--[[User:Asoknack|Asoknack]] 18:20, 9 October 2010 (UTC)
** allows the kernel to protect the resources with out understanding what the resource is [1]
*three way's to implement
* Hardware Mechanisms [1]
* Software caching [1]
* Downloading application code [1]
''' Downloading Code to the Kernel '''
* used to implement secure bindings , and improve performance[1]
** eliminate the number of kernel crossings [1]
** downloaded code can be run with out the application to be scheduled [2]
==== Visible Resource Revocation ====
* Used for most resources [1]
** allows for LibOS to help with deallocation [1]
** LibOS are able to garner what resources are scare [1]
* Slower than Invisible as application involvement is required [1]
** ex of when invisible is used is Processor addressing-context identifiers [1]
==== Abort Protocol ====
* allows the exokernel to take resources away from the LibOS [1]
* used when the LibOS fails to respond to the revocation request [1]
* Exokernel must be careful not to delete as the LibOS might need to write some system critical data to the resource [1]

== Comparisons ==
====Exokernel/Microkernel====
'''Similarities'''
* Limited functionality in kernel
** functionality in kernel to handle sharing of resources and security
** avoids programming directly to hardware which creates a dependency
* Additional functionality provided in user space as processes
'''Differences'''
* Minimal abstractions provided by the kernel
** Applications given more power in exokernel

====Exokernel/VM====
'''Similarities'''
* Idea of partitioning resources between applications/OSs
* "Control" of resource given
* Isolation from other applications/OSs
'''Differences'''
* Exokernel runs applications, VM runs OS
* VM uses a hostOS and guestOSs run on top
* Virtualization on VMs, Exokernel deals with real resources
* VM hides a lot of information because it emulates. Exokernel does not.

====Microkernel/VM====
'''Differences'''
* With a virtual machine, you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System.
* This can be costly but the benefits are that it's easier and all the standard OS features are available.

== References ==
[1]<nowiki> Engler, D. R., Kaashoek, M. F., and O'Toole, J. 1995. Exokernel: an operating system architecture for application-level resource management. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 251-266. DOI= http://doi.acm.org/10.1145/224056.224076 </nowiki>

[2]<nowiki>Engler, Dawson R. "The Exokernel Operating System Architecture." Diss. Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 1998. Web. 9 Oct. 2010. <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5054&rep=rep1&type=pdf>.</nowiki>

[3]<nowiki>Kaashoek, M. F., Engler, D. R., Ganger, G. R., Briceño, H. M., Hunt, R., Mazières, D., Pinckney, T., Grimm, R., Jannotti, J., and Mackenzie, K. 1997. Application performance and flexibility on exokernel systems. In Proceedings of the Sixteenth ACM Symposium on Operating Systems Principles (Saint Malo, France, October 05 - 08, 1997). W. M. Waite, Ed. SOSP '97. ACM, New York, NY, 52-65. DOI= http://doi.acm.org/10.1145/268998.266644 </nowiki>

[4]<nowiki>Vallee, G.; Naughton, T.; Engelmann, C.; Hong Ong; Scott, S.L.; , "System-Level Virtualization for High Performance Computing," Parallel, Distributed and Network-Based Processing, 2008. PDP 2008. 16th Euromicro Conference on , vol., no., pp.636-643, 13-15 Feb. 2008
DOI= http://doi.acm.org/10.1109/PDP.2008.85 </nowiki>

[5]<nowiki>Goldberg, R. P. 1973. Architecture of virtual machines. In Proceedings of the Workshop on Virtual Computer Systems (Cambridge, Massachusetts, United States, March 26 - 27, 1973). ACM, New York, NY, 74-112. DOI= http://doi.acm.org/10.1145/800122.803950 </nowiki>

[6]<nowiki>Vallee, G., Naughton, T., and Scott, S. L. 2007. System management software for virtual environments. In Proceedings of the 4th international Conference on Computing Frontiers (Ischia, Italy, May 07 - 09, 2007). CF '07. ACM, New York, NY, 153-160. DOI= http://doi.acm.org/10.1145/1242531.1242555 </nowiki>

[7]<nowiki>Liedtke, J. 1995. On micro-kernel construction. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 237-250. DOI= http://doi.acm.org/10.1145/224056.224075 </nowiki>

== Unsorted ==
An overview of exokernels,virtual machines, microkernels *[http://www2.supchurch.org:10999/files/school/classes/CSCI4730/Lectures/grad-structures.ppt Overview](Power Point) 
Should not be used as a source but an overview.

The original paper on [http://portal.acm.org/citation.cfm?id=224076 Exokernels] --[[User:Gautam|Gautam]] 22:39, 6 October 2010 (UTC)

Exokernel-
Minimalistic abstractions for developers
Exokernels can be seen as a good compromise between virtual machines and microkernels in the sense that exokernels can give that low level access to developers similar to direct access through a protected layer and at the same time can contain enough hardware abstraction to allow similar benefit of hiding the hardware resources to application programs.
Exokernel – fewest hardware abstractions to developer
Microkernel - is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system
Virtual machine is a simulation of any or devices requested by an application program
Exokenel – I’ve got a sound card
Virtual Machine – I’ve got the sound card you’re looking for, perfect virtual match
Microkernel – I’ve got sound card that plays Khazikstan sound format only
MicroKernel - Very small, very predictable, good for schedualing (QNX is a microkernel - POSIX compatable, benefits of running linux software like modern browsers)

This is some ideas I've got on this question, please contribute below
-Rovic

Outlining some main features here as I see them.

I found that the exokernel was an even lower-level design than the microkernel, closer to the hardware without abstraction. They have the same architecture with the basic functionality contained in the kernel to manage everyone. As the exokernel "gives" the resource to the application it can use the resource in isolation of other applications (until forced to shared) much like VMs receive their resources, either partitioned or virtualized, and execute as if its running on its own machine. There is this similar notion of partitioning the resources among applications/OS and allowing them to take control of what they have.

I'll locate some references later on. --[[User:Slay|Slay]] 15:00, 7 October 2010 (UTC)

I'm just going to post my answer for question 1 on the individuel assignment and hope it helps. --[[User:Aellebla|Aellebla]] 15:06, 12 October 2010 (UTC)

The design of the micro kernel was to take everything they could out of the Kernel and put it into a process. For ex, networking would be put into a process instead of staying in the kernel. The micro kernel dev's tried to keep lots of things in user space for efficiency. But one major problem with this is there would be a large amount of moving from a process to the kernel to user space and back again and this is a costly, non efficient process.It was an application specific OS, there was no multiplexing. With a virtual machine you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System. This is very heavy however but the benefits are that it‟s easy and all the standard OS features are there whereas in a microkernel setup they would not all be there and this can be seen as a compromise.

Exokernels can be seen as a compromise to virtual machines and microkernels because virtual machines emulate and exokernels do not. When you emulate something you hide a lot of the actual information because you wouldn‟t be able to see the „real‟ hardware. If we look at a virtual box setup running Linux, and we go look at all the hardware, it will be displayed as fake hardware.

Maybe we can have an introduction - paragraph or so on each type - then similarities - differences - and the compromise. I am going to do some research and writing this weekend and I will put some up -- Jslonosky

btw in my page (i guess you can call it that) i have some resources i have found --[[User:Asoknack|Asoknack]] 15:50, 8 October 2010 (UTC)
- Wow, nice man. I will go ahead and write up the descriptive paragraphs on each kernel and virtual machine if no one minds. --Jslonosky

I think we should divide up the paragraphs and proofread each others instead. (Are there only 4 of us?) I don't have much time to work on this today though but I'll try to work on it tomorrow morning. - Slay

Sure guy. That sounds good. There should be 5 or 6 of us though.. . Oh well. Their loss. I will do some before or after work today. Ill start with Microkernel since there is not a large amount of info here, and so we don't overlap each other - JSlonosky

yeah i think there was more like 7 of us btw if any one has any more information feel free to add it would be nice if you add the references so that way citing is really easy on acm.org it will auto give you the citation info (where it says Display Formats click on ACM Ref and new window with the citation info auto pop's up) --[[User:Asoknack|Asoknack]] 02:28, 11 October 2010 (UTC)

I added an outline of the similarities and differences. Add any more that I missed. These are from observations so I don't have any resources. -Slay
That's probably fine. Our textbook probably outlines some of them, so I am sure we can find a few there - JSlonosky

Talked to the teacher today and for VM he said we should focus on the implementation such as Xen and VMware , he also said to talk about para virtualization --[[User:Asoknack|Asoknack]] 18:42, 12 October 2010 (UTC)

== The Essay ==

Let's actually breakdown the essay into components then write it here.

We have our intro/thesis statement

...to the extent that exokernels be seen as a compromise between virtual machines and microkernels.
-I'll work on the initial intro, should have it ready by tonight. -Slade

3 paragraphs that prove it
Explain how the key design characteristics of these three system architectures compare with each other.

and conclusion

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-12T19:31:17Z

Asoknack: /* Thread's IPC */

== Microkernel ==
* Moving kernel functionality into processes contained in user space, e.g. file systems, drivers
* Keep basic functionality in kernel to handle sharing of resources
* Separation allows for manageability and security, corruption in one does not necessarily cause failure in system
* Large amount of moving from a process to Kernel to user space and back again, this is a costly operation.

----

''' Microkernel '''
* try's to minimize the amount of software that is mandatory or required [7]
advantages of Microkernel
* favors a modular system structure [7]
* one failure of a program does not impact any other programs [7]
* can support more than one api or strategies since all programs are separated [7]
==== Microkernel Concepts ====
* piece of code is allowed in the kernel only if moving it outside the kernel would adversely affect the system. [7]
* any subsystem program created must be independent of all other subsystem's, any subsystem that is used can guarantee this from all other subsystems [7]
===== Address Space =====
* a mapping that relates the physical page to the virtual page. [7]
* hide's the hardware's concept of address space [7]
* based off the idea of recursion each subsystem has it's own address space [7]
* the micro kernel provides 3 operations [7]
** Grant [7]
*** allows the owner to give a page to a recipient, provided the recipient want's it the page is removed from the owner's address space and but in the recipients. [7]
*** must be available to the owner. [7]
** Map [7]
*** allows the user to share a page with a recipient [7]
*** page is not removed from the owner's address space. [7]
** Flush [7]
*** remove's the page from all recipients address space [7]
*** how does this work with Grant --[[User:Asoknack|Asoknack]] 19:10, 12 October 2010 (UTC)
* allows memory management and paging out side the kernel
* Map and flush is required for memory manger's and pagers [7]
* can be used to implement access right's [7]
* controlling I/O Right's and driver's are not done at kernel level [7]

===== Thread's IPC =====
* Threads
** kernel [7]
*** Since a thread has an address space , all changes to the thread need to be done by the kernel [7]
* IPC
** IPC [7]
** grant and map also need IPC (So buye the priciple above this has to be in the kernel)[7]
** basic way for sub process to communicate. [7]
* Interupts
**

===== Unique Identifiers =====

== Virtual Machine ==
* Partitioning or virtualizing resources among OS virtualization running on top of host OS
* Virtualized OS believe running on full machine on its own

----
System Level Virtualization

=== VMM ===
* stands for Virtual Machine Monitor, also known as the hyper-visor[4]
* responsible for virtualization of hardware(mapping physical to virtual) and the VM that run on top of the virtuallized hardware [4]
* usually a small os with no drivers , so it is coupled with a linux distro that provides device / hardware access [4]
** the os that the VMM is using for driver's is called the hostOS [6]
*the hostOS provides login and physical access to the hardware as well as management for the VMM [6]
=== VM ===
* the OS that the vm is running is called the guestOS [6]
* the guestOS only sees resources that have been allocated to the VM [6]
==== three approaches ====
*Type I virtualization [5]
** runs off the physical hardware [4]
** Isolation of the guestOs from the hardware is done threw processe level protection meachnism[6]
*** ring 0 = VMM [6]
*** ring 1 = VM [6]
*** this means all instructions from the VM must go threw the VMM [6]
** since there can be multiple VM's on a computer the scheduling is done by the VMM [6]
** on boot the VMM creates a hardware platform for the VM [6]
** load's the VM kernel into virtual memory and then boot's it like a regular computer [6]
** ex. Xen [4]
*Type II virtualization [5]
** run off the host Os [4]
** ex. VMware , QEMU [4]
* Para-virtualization [6]
** Similar to Type but use the HostOs for Device driver access [6]

== Exokernel ==
* Micro-kernel architecture with limited abstractions, ask for resource, get resource not resource abstraction
* Less functionality provided by kernel, security and handling of resource sharing
* Once application receives resource, it can use it as it wishes/in control
* Keep the basic kernel to handle allocating resources and sharing rather than developing straight to the hardware

----
* multiplex resources securely providing protection to mutual distrustful application threw the use of secure binding's[1]
* Goal of the exokernel is to give LibOS maximum freedom with out allowing them to interfere with each other. to do this the exokernel separates protection from management in doing this it provide 3 important tasks[1]
** tracking ownership of resources [1]
** ensuring protection by guarding all resource usage and binding points (not to shure what binding points are)[1]
** revoking access to the resources [1]
* LibrayOS (LibOs)
** Reduces the number of kernel crossings[1]
** Not trusted by the exokernel so can be trusted by the application , Example given is a bad parameter passed to the LibOs only the application is affected.[1] (So LibOs cant interact with kernel ???)
** Any application running on the Exokernel can change the LibrayOs freely [1]
** Application that use LibOS that implement standard interfaces (POSIX) will be portable on any system with the same interface [1]
** LibOs can be made portable if it is designed to interact with a low-level machine independent level to hide hardware details [1]

=== Exokernel Design ===
==== Design Principles ====
*Securely Expose Hardware [1]
** an Exokernel tries to create low level primitives that the hardware resources can be accessed from, this also includes interrupts,exceptions [1]
** the exokernel also export privileged instructions to the LibOS so that traditional OS abstractions can be implemented (eg Process , address pace)[1]
** Exokernels should avoid resource management except when required protection ( allocation , revocation , ownership)[1]
** application based resource management is the best way to build flexible efficient flexible systems [1]
*Expose allocation[1]
** allow LibOs to request physical resources [1]
** resource allocation should not be automatic, the LibOS should participate in every single allocation decision [1]
*Expose Names[1]
** Use physical name's when ever possible[3] (not to sure what physical names are, I think it is as simple as what the hardware is called)--[[User:Asoknack|Asoknack]] 20:27, 9 October 2010 (UTC)
** Physical names capture useful information [3]
*** safer than and less resource intensive than virtual names as no translations are needed[3]
*Expose Revocation [1]
** use visible revocation protocol [1]
** allows well behaved LibOS to preform application level resource management [1]
** Visible revocation allows the LibOS to choose what instance of the resource to release[1](Visible means that when revocation happens the exokernel tell the LibOS that resource is being revoked)
''' Policy '''
* LibOS handle resource policy decisions
* Exokernels have a policy to decided between competing LibOS (Priority , share of resources)
** it enforces this threw allocation and deallocation (every thing can achieved threw this even what block to write and such)

==== Secure Bindings ====
* Used by the exokernel to allow the LibOS to bind to resources [1]
* Allows the separation of protection and resource use [1]
* only checks authorization during bind time [1]
** Application's with complex needs for resources only authorized during bind.[1]
* access checking is done during access time and there is no need to understand complex resources needs during access[1]
** (this means that the exokernel checks once to make sure an application has authorization once approved, when the application tries to use the resource the exokernel is only concerned about policy conflict's)--[[User:Asoknack|Asoknack]] 18:20, 9 October 2010 (UTC)
** allows the kernel to protect the resources with out understanding what the resource is [1]
*three way's to implement
* Hardware Mechanisms [1]
* Software caching [1]
* Downloading application code [1]
''' Downloading Code to the Kernel '''
* used to implement secure bindings , and improve performance[1]
** eliminate the number of kernel crossings [1]
** downloaded code can be run with out the application to be scheduled [2]
==== Visible Resource Revocation ====
* Used for most resources [1]
** allows for LibOS to help with deallocation [1]
** LibOS are able to garner what resources are scare [1]
* Slower than Invisible as application involvement is required [1]
** ex of when invisible is used is Processor addressing-context identifiers [1]
==== Abort Protocol ====
* allows the exokernel to take resources away from the LibOS [1]
* used when the LibOS fails to respond to the revocation request [1]
* Exokernel must be careful not to delete as the LibOS might need to write some system critical data to the resource [1]

== Comparisons ==
====Exokernel/Microkernel====
'''Similarities'''
* Limited functionality in kernel
** functionality in kernel to handle sharing of resources and security
** avoids programming directly to hardware which creates a dependency
* Additional functionality provided in user space as processes
'''Differences'''
* Minimal abstractions provided by the kernel
** Applications given more power in exokernel

====Exokernel/VM====
'''Similarities'''
* Idea of partitioning resources between applications/OSs
* "Control" of resource given
* Isolation from other applications/OSs
'''Differences'''
* Exokernel runs applications, VM runs OS
* VM uses a hostOS and guestOSs run on top
* Virtualization on VMs, Exokernel deals with real resources
* VM hides a lot of information because it emulates. Exokernel does not.

====Microkernel/VM====
'''Differences'''
* With a virtual machine, you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System.
* This can be costly but the benefits are that it's easier and all the standard OS features are available.

== References ==
[1]<nowiki> Engler, D. R., Kaashoek, M. F., and O'Toole, J. 1995. Exokernel: an operating system architecture for application-level resource management. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 251-266. DOI= http://doi.acm.org/10.1145/224056.224076 </nowiki>

[2]<nowiki>Engler, Dawson R. "The Exokernel Operating System Architecture." Diss. Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 1998. Web. 9 Oct. 2010. <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5054&rep=rep1&type=pdf>.</nowiki>

[3]<nowiki>Kaashoek, M. F., Engler, D. R., Ganger, G. R., Briceño, H. M., Hunt, R., Mazières, D., Pinckney, T., Grimm, R., Jannotti, J., and Mackenzie, K. 1997. Application performance and flexibility on exokernel systems. In Proceedings of the Sixteenth ACM Symposium on Operating Systems Principles (Saint Malo, France, October 05 - 08, 1997). W. M. Waite, Ed. SOSP '97. ACM, New York, NY, 52-65. DOI= http://doi.acm.org/10.1145/268998.266644 </nowiki>

[4]<nowiki>Vallee, G.; Naughton, T.; Engelmann, C.; Hong Ong; Scott, S.L.; , "System-Level Virtualization for High Performance Computing," Parallel, Distributed and Network-Based Processing, 2008. PDP 2008. 16th Euromicro Conference on , vol., no., pp.636-643, 13-15 Feb. 2008
DOI= http://doi.acm.org/10.1109/PDP.2008.85 </nowiki>

[5]<nowiki>Goldberg, R. P. 1973. Architecture of virtual machines. In Proceedings of the Workshop on Virtual Computer Systems (Cambridge, Massachusetts, United States, March 26 - 27, 1973). ACM, New York, NY, 74-112. DOI= http://doi.acm.org/10.1145/800122.803950 </nowiki>

[6]<nowiki>Vallee, G., Naughton, T., and Scott, S. L. 2007. System management software for virtual environments. In Proceedings of the 4th international Conference on Computing Frontiers (Ischia, Italy, May 07 - 09, 2007). CF '07. ACM, New York, NY, 153-160. DOI= http://doi.acm.org/10.1145/1242531.1242555 </nowiki>

[7]<nowiki>Liedtke, J. 1995. On micro-kernel construction. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 237-250. DOI= http://doi.acm.org/10.1145/224056.224075 </nowiki>

== Unsorted ==
An overview of exokernels,virtual machines, microkernels *[http://www2.supchurch.org:10999/files/school/classes/CSCI4730/Lectures/grad-structures.ppt Overview](Power Point) 
Should not be used as a source but an overview.

The original paper on [http://portal.acm.org/citation.cfm?id=224076 Exokernels] --[[User:Gautam|Gautam]] 22:39, 6 October 2010 (UTC)

Exokernel-
Minimalistic abstractions for developers
Exokernels can be seen as a good compromise between virtual machines and microkernels in the sense that exokernels can give that low level access to developers similar to direct access through a protected layer and at the same time can contain enough hardware abstraction to allow similar benefit of hiding the hardware resources to application programs.
Exokernel – fewest hardware abstractions to developer
Microkernel - is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system
Virtual machine is a simulation of any or devices requested by an application program
Exokenel – I’ve got a sound card
Virtual Machine – I’ve got the sound card you’re looking for, perfect virtual match
Microkernel – I’ve got sound card that plays Khazikstan sound format only
MicroKernel - Very small, very predictable, good for schedualing (QNX is a microkernel - POSIX compatable, benefits of running linux software like modern browsers)

This is some ideas I've got on this question, please contribute below
-Rovic

Outlining some main features here as I see them.

I found that the exokernel was an even lower-level design than the microkernel, closer to the hardware without abstraction. They have the same architecture with the basic functionality contained in the kernel to manage everyone. As the exokernel "gives" the resource to the application it can use the resource in isolation of other applications (until forced to shared) much like VMs receive their resources, either partitioned or virtualized, and execute as if its running on its own machine. There is this similar notion of partitioning the resources among applications/OS and allowing them to take control of what they have.

I'll locate some references later on. --[[User:Slay|Slay]] 15:00, 7 October 2010 (UTC)

I'm just going to post my answer for question 1 on the individuel assignment and hope it helps. --[[User:Aellebla|Aellebla]] 15:06, 12 October 2010 (UTC)

The design of the micro kernel was to take everything they could out of the Kernel and put it into a process. For ex, networking would be put into a process instead of staying in the kernel. The micro kernel dev's tried to keep lots of things in user space for efficiency. But one major problem with this is there would be a large amount of moving from a process to the kernel to user space and back again and this is a costly, non efficient process.It was an application specific OS, there was no multiplexing. With a virtual machine you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System. This is very heavy however but the benefits are that it‟s easy and all the standard OS features are there whereas in a microkernel setup they would not all be there and this can be seen as a compromise.

Exokernels can be seen as a compromise to virtual machines and microkernels because virtual machines emulate and exokernels do not. When you emulate something you hide a lot of the actual information because you wouldn‟t be able to see the „real‟ hardware. If we look at a virtual box setup running Linux, and we go look at all the hardware, it will be displayed as fake hardware.

Maybe we can have an introduction - paragraph or so on each type - then similarities - differences - and the compromise. I am going to do some research and writing this weekend and I will put some up -- Jslonosky

btw in my page (i guess you can call it that) i have some resources i have found --[[User:Asoknack|Asoknack]] 15:50, 8 October 2010 (UTC)
- Wow, nice man. I will go ahead and write up the descriptive paragraphs on each kernel and virtual machine if no one minds. --Jslonosky

I think we should divide up the paragraphs and proofread each others instead. (Are there only 4 of us?) I don't have much time to work on this today though but I'll try to work on it tomorrow morning. - Slay

Sure guy. That sounds good. There should be 5 or 6 of us though.. . Oh well. Their loss. I will do some before or after work today. Ill start with Microkernel since there is not a large amount of info here, and so we don't overlap each other - JSlonosky

yeah i think there was more like 7 of us btw if any one has any more information feel free to add it would be nice if you add the references so that way citing is really easy on acm.org it will auto give you the citation info (where it says Display Formats click on ACM Ref and new window with the citation info auto pop's up) --[[User:Asoknack|Asoknack]] 02:28, 11 October 2010 (UTC)

I added an outline of the similarities and differences. Add any more that I missed. These are from observations so I don't have any resources. -Slay
That's probably fine. Our textbook probably outlines some of them, so I am sure we can find a few there - JSlonosky

Talked to the teacher today and for VM he said we should focus on the implementation such as Xen and VMware , he also said to talk about para virtualization --[[User:Asoknack|Asoknack]] 18:42, 12 October 2010 (UTC)

== The Essay ==

Let's actually breakdown the essay into components then write it here.

We have our intro/thesis statement

...to the extent that exokernels be seen as a compromise between virtual machines and microkernels.
-I'll work on the initial intro, should have it ready by tonight. -Slade

3 paragraphs that prove it
Explain how the key design characteristics of these three system architectures compare with each other.

and conclusion

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-12T19:20:55Z

Asoknack: /* Address Space */

== Microkernel ==
* Moving kernel functionality into processes contained in user space, e.g. file systems, drivers
* Keep basic functionality in kernel to handle sharing of resources
* Separation allows for manageability and security, corruption in one does not necessarily cause failure in system
* Large amount of moving from a process to Kernel to user space and back again, this is a costly operation.

----

''' Microkernel '''
* try's to minimize the amount of software that is mandatory or required [7]
advantages of Microkernel
* favors a modular system structure [7]
* one failure of a program does not impact any other programs [7]
* can support more than one api or strategies since all programs are separated [7]
==== Microkernel Concepts ====
* piece of code is allowed in the kernel only if moving it outside the kernel would adversely affect the system. [7]
* any subsystem program created must be independent of all other subsystem's, any subsystem that is used can guarantee this from all other subsystems [7]
===== Address Space =====
* a mapping that relates the physical page to the virtual page. [7]
* hide's the hardware's concept of address space [7]
* based off the idea of recursion each subsystem has it's own address space [7]
* the micro kernel provides 3 operations [7]
** Grant [7]
*** allows the owner to give a page to a recipient, provided the recipient want's it the page is removed from the owner's address space and but in the recipients. [7]
*** must be available to the owner. [7]
** Map [7]
*** allows the user to share a page with a recipient [7]
*** page is not removed from the owner's address space. [7]
** Flush [7]
*** remove's the page from all recipients address space [7]
*** how does this work with Grant --[[User:Asoknack|Asoknack]] 19:10, 12 October 2010 (UTC)
* allows memory management and paging out side the kernel
* Map and flush is required for memory manger's and pagers [7]
* can be used to implement access right's [7]
* controlling I/O Right's and driver's are not done at kernel level [7]

===== Thread's IPC =====
===== Unique Identifiers =====

== Virtual Machine ==
* Partitioning or virtualizing resources among OS virtualization running on top of host OS
* Virtualized OS believe running on full machine on its own

----
System Level Virtualization

=== VMM ===
* stands for Virtual Machine Monitor, also known as the hyper-visor[4]
* responsible for virtualization of hardware(mapping physical to virtual) and the VM that run on top of the virtuallized hardware [4]
* usually a small os with no drivers , so it is coupled with a linux distro that provides device / hardware access [4]
** the os that the VMM is using for driver's is called the hostOS [6]
*the hostOS provides login and physical access to the hardware as well as management for the VMM [6]
=== VM ===
* the OS that the vm is running is called the guestOS [6]
* the guestOS only sees resources that have been allocated to the VM [6]
==== three approaches ====
*Type I virtualization [5]
** runs off the physical hardware [4]
** Isolation of the guestOs from the hardware is done threw processe level protection meachnism[6]
*** ring 0 = VMM [6]
*** ring 1 = VM [6]
*** this means all instructions from the VM must go threw the VMM [6]
** since there can be multiple VM's on a computer the scheduling is done by the VMM [6]
** on boot the VMM creates a hardware platform for the VM [6]
** load's the VM kernel into virtual memory and then boot's it like a regular computer [6]
** ex. Xen [4]
*Type II virtualization [5]
** run off the host Os [4]
** ex. VMware , QEMU [4]
* Para-virtualization [6]
** Similar to Type but use the HostOs for Device driver access [6]

== Exokernel ==
* Micro-kernel architecture with limited abstractions, ask for resource, get resource not resource abstraction
* Less functionality provided by kernel, security and handling of resource sharing
* Once application receives resource, it can use it as it wishes/in control
* Keep the basic kernel to handle allocating resources and sharing rather than developing straight to the hardware

----
* multiplex resources securely providing protection to mutual distrustful application threw the use of secure binding's[1]
* Goal of the exokernel is to give LibOS maximum freedom with out allowing them to interfere with each other. to do this the exokernel separates protection from management in doing this it provide 3 important tasks[1]
** tracking ownership of resources [1]
** ensuring protection by guarding all resource usage and binding points (not to shure what binding points are)[1]
** revoking access to the resources [1]
* LibrayOS (LibOs)
** Reduces the number of kernel crossings[1]
** Not trusted by the exokernel so can be trusted by the application , Example given is a bad parameter passed to the LibOs only the application is affected.[1] (So LibOs cant interact with kernel ???)
** Any application running on the Exokernel can change the LibrayOs freely [1]
** Application that use LibOS that implement standard interfaces (POSIX) will be portable on any system with the same interface [1]
** LibOs can be made portable if it is designed to interact with a low-level machine independent level to hide hardware details [1]

=== Exokernel Design ===
==== Design Principles ====
*Securely Expose Hardware [1]
** an Exokernel tries to create low level primitives that the hardware resources can be accessed from, this also includes interrupts,exceptions [1]
** the exokernel also export privileged instructions to the LibOS so that traditional OS abstractions can be implemented (eg Process , address pace)[1]
** Exokernels should avoid resource management except when required protection ( allocation , revocation , ownership)[1]
** application based resource management is the best way to build flexible efficient flexible systems [1]
*Expose allocation[1]
** allow LibOs to request physical resources [1]
** resource allocation should not be automatic, the LibOS should participate in every single allocation decision [1]
*Expose Names[1]
** Use physical name's when ever possible[3] (not to sure what physical names are, I think it is as simple as what the hardware is called)--[[User:Asoknack|Asoknack]] 20:27, 9 October 2010 (UTC)
** Physical names capture useful information [3]
*** safer than and less resource intensive than virtual names as no translations are needed[3]
*Expose Revocation [1]
** use visible revocation protocol [1]
** allows well behaved LibOS to preform application level resource management [1]
** Visible revocation allows the LibOS to choose what instance of the resource to release[1](Visible means that when revocation happens the exokernel tell the LibOS that resource is being revoked)
''' Policy '''
* LibOS handle resource policy decisions
* Exokernels have a policy to decided between competing LibOS (Priority , share of resources)
** it enforces this threw allocation and deallocation (every thing can achieved threw this even what block to write and such)

==== Secure Bindings ====
* Used by the exokernel to allow the LibOS to bind to resources [1]
* Allows the separation of protection and resource use [1]
* only checks authorization during bind time [1]
** Application's with complex needs for resources only authorized during bind.[1]
* access checking is done during access time and there is no need to understand complex resources needs during access[1]
** (this means that the exokernel checks once to make sure an application has authorization once approved, when the application tries to use the resource the exokernel is only concerned about policy conflict's)--[[User:Asoknack|Asoknack]] 18:20, 9 October 2010 (UTC)
** allows the kernel to protect the resources with out understanding what the resource is [1]
*three way's to implement
* Hardware Mechanisms [1]
* Software caching [1]
* Downloading application code [1]
''' Downloading Code to the Kernel '''
* used to implement secure bindings , and improve performance[1]
** eliminate the number of kernel crossings [1]
** downloaded code can be run with out the application to be scheduled [2]
==== Visible Resource Revocation ====
* Used for most resources [1]
** allows for LibOS to help with deallocation [1]
** LibOS are able to garner what resources are scare [1]
* Slower than Invisible as application involvement is required [1]
** ex of when invisible is used is Processor addressing-context identifiers [1]
==== Abort Protocol ====
* allows the exokernel to take resources away from the LibOS [1]
* used when the LibOS fails to respond to the revocation request [1]
* Exokernel must be careful not to delete as the LibOS might need to write some system critical data to the resource [1]

== Comparisons ==
====Exokernel/Microkernel====
'''Similarities'''
* Limited functionality in kernel
** functionality in kernel to handle sharing of resources and security
** avoids programming directly to hardware which creates a dependency
* Additional functionality provided in user space as processes
'''Differences'''
* Minimal abstractions provided by the kernel
** Applications given more power in exokernel

====Exokernel/VM====
'''Similarities'''
* Idea of partitioning resources between applications/OSs
* "Control" of resource given
* Isolation from other applications/OSs
'''Differences'''
* Exokernel runs applications, VM runs OS
* VM uses a hostOS and guestOSs run on top
* Virtualization on VMs, Exokernel deals with real resources
* VM hides a lot of information because it emulates. Exokernel does not.

====Microkernel/VM====
'''Differences'''
* With a virtual machine, you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System.
* This can be costly but the benefits are that it's easier and all the standard OS features are available.

== References ==
[1]<nowiki> Engler, D. R., Kaashoek, M. F., and O'Toole, J. 1995. Exokernel: an operating system architecture for application-level resource management. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 251-266. DOI= http://doi.acm.org/10.1145/224056.224076 </nowiki>

[2]<nowiki>Engler, Dawson R. "The Exokernel Operating System Architecture." Diss. Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 1998. Web. 9 Oct. 2010. <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5054&rep=rep1&type=pdf>.</nowiki>

[3]<nowiki>Kaashoek, M. F., Engler, D. R., Ganger, G. R., Briceño, H. M., Hunt, R., Mazières, D., Pinckney, T., Grimm, R., Jannotti, J., and Mackenzie, K. 1997. Application performance and flexibility on exokernel systems. In Proceedings of the Sixteenth ACM Symposium on Operating Systems Principles (Saint Malo, France, October 05 - 08, 1997). W. M. Waite, Ed. SOSP '97. ACM, New York, NY, 52-65. DOI= http://doi.acm.org/10.1145/268998.266644 </nowiki>

[4]<nowiki>Vallee, G.; Naughton, T.; Engelmann, C.; Hong Ong; Scott, S.L.; , "System-Level Virtualization for High Performance Computing," Parallel, Distributed and Network-Based Processing, 2008. PDP 2008. 16th Euromicro Conference on , vol., no., pp.636-643, 13-15 Feb. 2008
DOI= http://doi.acm.org/10.1109/PDP.2008.85 </nowiki>

[5]<nowiki>Goldberg, R. P. 1973. Architecture of virtual machines. In Proceedings of the Workshop on Virtual Computer Systems (Cambridge, Massachusetts, United States, March 26 - 27, 1973). ACM, New York, NY, 74-112. DOI= http://doi.acm.org/10.1145/800122.803950 </nowiki>

[6]<nowiki>Vallee, G., Naughton, T., and Scott, S. L. 2007. System management software for virtual environments. In Proceedings of the 4th international Conference on Computing Frontiers (Ischia, Italy, May 07 - 09, 2007). CF '07. ACM, New York, NY, 153-160. DOI= http://doi.acm.org/10.1145/1242531.1242555 </nowiki>

[7]<nowiki>Liedtke, J. 1995. On micro-kernel construction. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 237-250. DOI= http://doi.acm.org/10.1145/224056.224075 </nowiki>

== Unsorted ==
An overview of exokernels,virtual machines, microkernels *[http://www2.supchurch.org:10999/files/school/classes/CSCI4730/Lectures/grad-structures.ppt Overview](Power Point) 
Should not be used as a source but an overview.

The original paper on [http://portal.acm.org/citation.cfm?id=224076 Exokernels] --[[User:Gautam|Gautam]] 22:39, 6 October 2010 (UTC)

Exokernel-
Minimalistic abstractions for developers
Exokernels can be seen as a good compromise between virtual machines and microkernels in the sense that exokernels can give that low level access to developers similar to direct access through a protected layer and at the same time can contain enough hardware abstraction to allow similar benefit of hiding the hardware resources to application programs.
Exokernel – fewest hardware abstractions to developer
Microkernel - is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system
Virtual machine is a simulation of any or devices requested by an application program
Exokenel – I’ve got a sound card
Virtual Machine – I’ve got the sound card you’re looking for, perfect virtual match
Microkernel – I’ve got sound card that plays Khazikstan sound format only
MicroKernel - Very small, very predictable, good for schedualing (QNX is a microkernel - POSIX compatable, benefits of running linux software like modern browsers)

This is some ideas I've got on this question, please contribute below
-Rovic

Outlining some main features here as I see them.

I found that the exokernel was an even lower-level design than the microkernel, closer to the hardware without abstraction. They have the same architecture with the basic functionality contained in the kernel to manage everyone. As the exokernel "gives" the resource to the application it can use the resource in isolation of other applications (until forced to shared) much like VMs receive their resources, either partitioned or virtualized, and execute as if its running on its own machine. There is this similar notion of partitioning the resources among applications/OS and allowing them to take control of what they have.

I'll locate some references later on. --[[User:Slay|Slay]] 15:00, 7 October 2010 (UTC)

I'm just going to post my answer for question 1 on the individuel assignment and hope it helps. --[[User:Aellebla|Aellebla]] 15:06, 12 October 2010 (UTC)

The design of the micro kernel was to take everything they could out of the Kernel and put it into a process. For ex, networking would be put into a process instead of staying in the kernel. The micro kernel dev's tried to keep lots of things in user space for efficiency. But one major problem with this is there would be a large amount of moving from a process to the kernel to user space and back again and this is a costly, non efficient process.It was an application specific OS, there was no multiplexing. With a virtual machine you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System. This is very heavy however but the benefits are that it‟s easy and all the standard OS features are there whereas in a microkernel setup they would not all be there and this can be seen as a compromise.

Exokernels can be seen as a compromise to virtual machines and microkernels because virtual machines emulate and exokernels do not. When you emulate something you hide a lot of the actual information because you wouldn‟t be able to see the „real‟ hardware. If we look at a virtual box setup running Linux, and we go look at all the hardware, it will be displayed as fake hardware.

Maybe we can have an introduction - paragraph or so on each type - then similarities - differences - and the compromise. I am going to do some research and writing this weekend and I will put some up -- Jslonosky

btw in my page (i guess you can call it that) i have some resources i have found --[[User:Asoknack|Asoknack]] 15:50, 8 October 2010 (UTC)
- Wow, nice man. I will go ahead and write up the descriptive paragraphs on each kernel and virtual machine if no one minds. --Jslonosky

I think we should divide up the paragraphs and proofread each others instead. (Are there only 4 of us?) I don't have much time to work on this today though but I'll try to work on it tomorrow morning. - Slay

Sure guy. That sounds good. There should be 5 or 6 of us though.. . Oh well. Their loss. I will do some before or after work today. Ill start with Microkernel since there is not a large amount of info here, and so we don't overlap each other - JSlonosky

yeah i think there was more like 7 of us btw if any one has any more information feel free to add it would be nice if you add the references so that way citing is really easy on acm.org it will auto give you the citation info (where it says Display Formats click on ACM Ref and new window with the citation info auto pop's up) --[[User:Asoknack|Asoknack]] 02:28, 11 October 2010 (UTC)

I added an outline of the similarities and differences. Add any more that I missed. These are from observations so I don't have any resources. -Slay
That's probably fine. Our textbook probably outlines some of them, so I am sure we can find a few there - JSlonosky

Talked to the teacher today and for VM he said we should focus on the implementation such as Xen and VMware , he also said to talk about para virtualization --[[User:Asoknack|Asoknack]] 18:42, 12 October 2010 (UTC)

== The Essay ==

Let's actually breakdown the essay into components then write it here.

We have our intro/thesis statement

...to the extent that exokernels be seen as a compromise between virtual machines and microkernels.
-I'll work on the initial intro, should have it ready by tonight. -Slade

3 paragraphs that prove it
Explain how the key design characteristics of these three system architectures compare with each other.

and conclusion

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-12T19:20:32Z

Asoknack: /* Address Space */

== Microkernel ==
* Moving kernel functionality into processes contained in user space, e.g. file systems, drivers
* Keep basic functionality in kernel to handle sharing of resources
* Separation allows for manageability and security, corruption in one does not necessarily cause failure in system
* Large amount of moving from a process to Kernel to user space and back again, this is a costly operation.

----

''' Microkernel '''
* try's to minimize the amount of software that is mandatory or required [7]
advantages of Microkernel
* favors a modular system structure [7]
* one failure of a program does not impact any other programs [7]
* can support more than one api or strategies since all programs are separated [7]
==== Microkernel Concepts ====
* piece of code is allowed in the kernel only if moving it outside the kernel would adversely affect the system. [7]
* any subsystem program created must be independent of all other subsystem's, any subsystem that is used can guarantee this from all other subsystems [7]
===== Address Space =====
* a mapping that relates the physical page to the virtual page. [7]
* hide's the hardware's concept of address space [7]
* based off the idea of recursion each subsystem has it's own address space [7]
* the micro kernel provides 3 operations [7]
** Grant [7]
*** allows the owner to give a page to a recipient, provided the recipient want's it the page is removed from the owner's address space and but in the recipients. [7]
*** must be available to the owner. [7]
** Map [7]
*** allows the user to share a page with a recipient [7]
*** page is not removed from the owner's address space. [7]
** Flush [7]
*** remove's the page from all recipients address space
*** how does this work with Grant --[[User:Asoknack|Asoknack]] 19:10, 12 October 2010 (UTC)
* allows memory management and paging out side the kernel
* Map and flush is required for memory manger's and pagers [7]
* can be used to implement acces right's
* controlling I/O Right's and driver's are not done at kernel level

===== Thread's IPC =====
===== Unique Identifiers =====

== Virtual Machine ==
* Partitioning or virtualizing resources among OS virtualization running on top of host OS
* Virtualized OS believe running on full machine on its own

----
System Level Virtualization

=== VMM ===
* stands for Virtual Machine Monitor, also known as the hyper-visor[4]
* responsible for virtualization of hardware(mapping physical to virtual) and the VM that run on top of the virtuallized hardware [4]
* usually a small os with no drivers , so it is coupled with a linux distro that provides device / hardware access [4]
** the os that the VMM is using for driver's is called the hostOS [6]
*the hostOS provides login and physical access to the hardware as well as management for the VMM [6]
=== VM ===
* the OS that the vm is running is called the guestOS [6]
* the guestOS only sees resources that have been allocated to the VM [6]
==== three approaches ====
*Type I virtualization [5]
** runs off the physical hardware [4]
** Isolation of the guestOs from the hardware is done threw processe level protection meachnism[6]
*** ring 0 = VMM [6]
*** ring 1 = VM [6]
*** this means all instructions from the VM must go threw the VMM [6]
** since there can be multiple VM's on a computer the scheduling is done by the VMM [6]
** on boot the VMM creates a hardware platform for the VM [6]
** load's the VM kernel into virtual memory and then boot's it like a regular computer [6]
** ex. Xen [4]
*Type II virtualization [5]
** run off the host Os [4]
** ex. VMware , QEMU [4]
* Para-virtualization [6]
** Similar to Type but use the HostOs for Device driver access [6]

== Exokernel ==
* Micro-kernel architecture with limited abstractions, ask for resource, get resource not resource abstraction
* Less functionality provided by kernel, security and handling of resource sharing
* Once application receives resource, it can use it as it wishes/in control
* Keep the basic kernel to handle allocating resources and sharing rather than developing straight to the hardware

----
* multiplex resources securely providing protection to mutual distrustful application threw the use of secure binding's[1]
* Goal of the exokernel is to give LibOS maximum freedom with out allowing them to interfere with each other. to do this the exokernel separates protection from management in doing this it provide 3 important tasks[1]
** tracking ownership of resources [1]
** ensuring protection by guarding all resource usage and binding points (not to shure what binding points are)[1]
** revoking access to the resources [1]
* LibrayOS (LibOs)
** Reduces the number of kernel crossings[1]
** Not trusted by the exokernel so can be trusted by the application , Example given is a bad parameter passed to the LibOs only the application is affected.[1] (So LibOs cant interact with kernel ???)
** Any application running on the Exokernel can change the LibrayOs freely [1]
** Application that use LibOS that implement standard interfaces (POSIX) will be portable on any system with the same interface [1]
** LibOs can be made portable if it is designed to interact with a low-level machine independent level to hide hardware details [1]

=== Exokernel Design ===
==== Design Principles ====
*Securely Expose Hardware [1]
** an Exokernel tries to create low level primitives that the hardware resources can be accessed from, this also includes interrupts,exceptions [1]
** the exokernel also export privileged instructions to the LibOS so that traditional OS abstractions can be implemented (eg Process , address pace)[1]
** Exokernels should avoid resource management except when required protection ( allocation , revocation , ownership)[1]
** application based resource management is the best way to build flexible efficient flexible systems [1]
*Expose allocation[1]
** allow LibOs to request physical resources [1]
** resource allocation should not be automatic, the LibOS should participate in every single allocation decision [1]
*Expose Names[1]
** Use physical name's when ever possible[3] (not to sure what physical names are, I think it is as simple as what the hardware is called)--[[User:Asoknack|Asoknack]] 20:27, 9 October 2010 (UTC)
** Physical names capture useful information [3]
*** safer than and less resource intensive than virtual names as no translations are needed[3]
*Expose Revocation [1]
** use visible revocation protocol [1]
** allows well behaved LibOS to preform application level resource management [1]
** Visible revocation allows the LibOS to choose what instance of the resource to release[1](Visible means that when revocation happens the exokernel tell the LibOS that resource is being revoked)
''' Policy '''
* LibOS handle resource policy decisions
* Exokernels have a policy to decided between competing LibOS (Priority , share of resources)
** it enforces this threw allocation and deallocation (every thing can achieved threw this even what block to write and such)

==== Secure Bindings ====
* Used by the exokernel to allow the LibOS to bind to resources [1]
* Allows the separation of protection and resource use [1]
* only checks authorization during bind time [1]
** Application's with complex needs for resources only authorized during bind.[1]
* access checking is done during access time and there is no need to understand complex resources needs during access[1]
** (this means that the exokernel checks once to make sure an application has authorization once approved, when the application tries to use the resource the exokernel is only concerned about policy conflict's)--[[User:Asoknack|Asoknack]] 18:20, 9 October 2010 (UTC)
** allows the kernel to protect the resources with out understanding what the resource is [1]
*three way's to implement
* Hardware Mechanisms [1]
* Software caching [1]
* Downloading application code [1]
''' Downloading Code to the Kernel '''
* used to implement secure bindings , and improve performance[1]
** eliminate the number of kernel crossings [1]
** downloaded code can be run with out the application to be scheduled [2]
==== Visible Resource Revocation ====
* Used for most resources [1]
** allows for LibOS to help with deallocation [1]
** LibOS are able to garner what resources are scare [1]
* Slower than Invisible as application involvement is required [1]
** ex of when invisible is used is Processor addressing-context identifiers [1]
==== Abort Protocol ====
* allows the exokernel to take resources away from the LibOS [1]
* used when the LibOS fails to respond to the revocation request [1]
* Exokernel must be careful not to delete as the LibOS might need to write some system critical data to the resource [1]

== Comparisons ==
====Exokernel/Microkernel====
'''Similarities'''
* Limited functionality in kernel
** functionality in kernel to handle sharing of resources and security
** avoids programming directly to hardware which creates a dependency
* Additional functionality provided in user space as processes
'''Differences'''
* Minimal abstractions provided by the kernel
** Applications given more power in exokernel

====Exokernel/VM====
'''Similarities'''
* Idea of partitioning resources between applications/OSs
* "Control" of resource given
* Isolation from other applications/OSs
'''Differences'''
* Exokernel runs applications, VM runs OS
* VM uses a hostOS and guestOSs run on top
* Virtualization on VMs, Exokernel deals with real resources
* VM hides a lot of information because it emulates. Exokernel does not.

====Microkernel/VM====
'''Differences'''
* With a virtual machine, you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System.
* This can be costly but the benefits are that it's easier and all the standard OS features are available.

== References ==
[1]<nowiki> Engler, D. R., Kaashoek, M. F., and O'Toole, J. 1995. Exokernel: an operating system architecture for application-level resource management. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 251-266. DOI= http://doi.acm.org/10.1145/224056.224076 </nowiki>

[2]<nowiki>Engler, Dawson R. "The Exokernel Operating System Architecture." Diss. Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 1998. Web. 9 Oct. 2010. <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5054&rep=rep1&type=pdf>.</nowiki>

[3]<nowiki>Kaashoek, M. F., Engler, D. R., Ganger, G. R., Briceño, H. M., Hunt, R., Mazières, D., Pinckney, T., Grimm, R., Jannotti, J., and Mackenzie, K. 1997. Application performance and flexibility on exokernel systems. In Proceedings of the Sixteenth ACM Symposium on Operating Systems Principles (Saint Malo, France, October 05 - 08, 1997). W. M. Waite, Ed. SOSP '97. ACM, New York, NY, 52-65. DOI= http://doi.acm.org/10.1145/268998.266644 </nowiki>

[4]<nowiki>Vallee, G.; Naughton, T.; Engelmann, C.; Hong Ong; Scott, S.L.; , "System-Level Virtualization for High Performance Computing," Parallel, Distributed and Network-Based Processing, 2008. PDP 2008. 16th Euromicro Conference on , vol., no., pp.636-643, 13-15 Feb. 2008
DOI= http://doi.acm.org/10.1109/PDP.2008.85 </nowiki>

[5]<nowiki>Goldberg, R. P. 1973. Architecture of virtual machines. In Proceedings of the Workshop on Virtual Computer Systems (Cambridge, Massachusetts, United States, March 26 - 27, 1973). ACM, New York, NY, 74-112. DOI= http://doi.acm.org/10.1145/800122.803950 </nowiki>

[6]<nowiki>Vallee, G., Naughton, T., and Scott, S. L. 2007. System management software for virtual environments. In Proceedings of the 4th international Conference on Computing Frontiers (Ischia, Italy, May 07 - 09, 2007). CF '07. ACM, New York, NY, 153-160. DOI= http://doi.acm.org/10.1145/1242531.1242555 </nowiki>

[7]<nowiki>Liedtke, J. 1995. On micro-kernel construction. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 237-250. DOI= http://doi.acm.org/10.1145/224056.224075 </nowiki>

== Unsorted ==
An overview of exokernels,virtual machines, microkernels *[http://www2.supchurch.org:10999/files/school/classes/CSCI4730/Lectures/grad-structures.ppt Overview](Power Point) 
Should not be used as a source but an overview.

The original paper on [http://portal.acm.org/citation.cfm?id=224076 Exokernels] --[[User:Gautam|Gautam]] 22:39, 6 October 2010 (UTC)

Exokernel-
Minimalistic abstractions for developers
Exokernels can be seen as a good compromise between virtual machines and microkernels in the sense that exokernels can give that low level access to developers similar to direct access through a protected layer and at the same time can contain enough hardware abstraction to allow similar benefit of hiding the hardware resources to application programs.
Exokernel – fewest hardware abstractions to developer
Microkernel - is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system
Virtual machine is a simulation of any or devices requested by an application program
Exokenel – I’ve got a sound card
Virtual Machine – I’ve got the sound card you’re looking for, perfect virtual match
Microkernel – I’ve got sound card that plays Khazikstan sound format only
MicroKernel - Very small, very predictable, good for schedualing (QNX is a microkernel - POSIX compatable, benefits of running linux software like modern browsers)

This is some ideas I've got on this question, please contribute below
-Rovic

Outlining some main features here as I see them.

I found that the exokernel was an even lower-level design than the microkernel, closer to the hardware without abstraction. They have the same architecture with the basic functionality contained in the kernel to manage everyone. As the exokernel "gives" the resource to the application it can use the resource in isolation of other applications (until forced to shared) much like VMs receive their resources, either partitioned or virtualized, and execute as if its running on its own machine. There is this similar notion of partitioning the resources among applications/OS and allowing them to take control of what they have.

I'll locate some references later on. --[[User:Slay|Slay]] 15:00, 7 October 2010 (UTC)

I'm just going to post my answer for question 1 on the individuel assignment and hope it helps. --[[User:Aellebla|Aellebla]] 15:06, 12 October 2010 (UTC)

The design of the micro kernel was to take everything they could out of the Kernel and put it into a process. For ex, networking would be put into a process instead of staying in the kernel. The micro kernel dev's tried to keep lots of things in user space for efficiency. But one major problem with this is there would be a large amount of moving from a process to the kernel to user space and back again and this is a costly, non efficient process.It was an application specific OS, there was no multiplexing. With a virtual machine you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System. This is very heavy however but the benefits are that it‟s easy and all the standard OS features are there whereas in a microkernel setup they would not all be there and this can be seen as a compromise.

Exokernels can be seen as a compromise to virtual machines and microkernels because virtual machines emulate and exokernels do not. When you emulate something you hide a lot of the actual information because you wouldn‟t be able to see the „real‟ hardware. If we look at a virtual box setup running Linux, and we go look at all the hardware, it will be displayed as fake hardware.

Maybe we can have an introduction - paragraph or so on each type - then similarities - differences - and the compromise. I am going to do some research and writing this weekend and I will put some up -- Jslonosky

btw in my page (i guess you can call it that) i have some resources i have found --[[User:Asoknack|Asoknack]] 15:50, 8 October 2010 (UTC)
- Wow, nice man. I will go ahead and write up the descriptive paragraphs on each kernel and virtual machine if no one minds. --Jslonosky

I think we should divide up the paragraphs and proofread each others instead. (Are there only 4 of us?) I don't have much time to work on this today though but I'll try to work on it tomorrow morning. - Slay

Sure guy. That sounds good. There should be 5 or 6 of us though.. . Oh well. Their loss. I will do some before or after work today. Ill start with Microkernel since there is not a large amount of info here, and so we don't overlap each other - JSlonosky

yeah i think there was more like 7 of us btw if any one has any more information feel free to add it would be nice if you add the references so that way citing is really easy on acm.org it will auto give you the citation info (where it says Display Formats click on ACM Ref and new window with the citation info auto pop's up) --[[User:Asoknack|Asoknack]] 02:28, 11 October 2010 (UTC)

I added an outline of the similarities and differences. Add any more that I missed. These are from observations so I don't have any resources. -Slay
That's probably fine. Our textbook probably outlines some of them, so I am sure we can find a few there - JSlonosky

Talked to the teacher today and for VM he said we should focus on the implementation such as Xen and VMware , he also said to talk about para virtualization --[[User:Asoknack|Asoknack]] 18:42, 12 October 2010 (UTC)

== The Essay ==

Let's actually breakdown the essay into components then write it here.

We have our intro/thesis statement

...to the extent that exokernels be seen as a compromise between virtual machines and microkernels.
-I'll work on the initial intro, should have it ready by tonight. -Slade

3 paragraphs that prove it
Explain how the key design characteristics of these three system architectures compare with each other.

and conclusion

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-12T19:14:01Z

Asoknack: /* Unsorted */

== Microkernel ==
* Moving kernel functionality into processes contained in user space, e.g. file systems, drivers
* Keep basic functionality in kernel to handle sharing of resources
* Separation allows for manageability and security, corruption in one does not necessarily cause failure in system
* Large amount of moving from a process to Kernel to user space and back again, this is a costly operation.

----

''' Microkernel '''
* try's to minimize the amount of software that is mandatory or required [7]
advantages of Microkernel
* favors a modular system structure [7]
* one failure of a program does not impact any other programs [7]
* can support more than one api or strategies since all programs are separated [7]
==== Microkernel Concepts ====
* piece of code is allowed in the kernel only if moving it outside the kernel would adversely affect the system. [7]
* any subsystem program created must be independent of all other subsystem's, any subsystem that is used can guarantee this from all other subsystems [7]
===== Address Space =====
* a mapping that relates the physical page to the virtual page. [7]
* hide's the hardware's concept of address space [7]
* based off the idea of recursion each subsystem has it's own address space [7]
* the micro kernel provides 3 operations [7]
** Grant [7]
*** allows the owner to give a page to a recipient, provided the recipient want's it the page is removed from the owner's address space and but in the recipients. [7]
*** must be available to the owner. [7]
** Map [7]
*** allows the user to share a page with a recipient [7]
*** page is not removed from the owner's address space. [7]
** Flush [7]
*** remove's the page from all recipients address space
*** how does this work with Grant --[[User:Asoknack|Asoknack]] 19:10, 12 October 2010 (UTC)

===== Thread's IPC =====
===== Unique Identifiers =====

== Virtual Machine ==
* Partitioning or virtualizing resources among OS virtualization running on top of host OS
* Virtualized OS believe running on full machine on its own

----
System Level Virtualization

=== VMM ===
* stands for Virtual Machine Monitor, also known as the hyper-visor[4]
* responsible for virtualization of hardware(mapping physical to virtual) and the VM that run on top of the virtuallized hardware [4]
* usually a small os with no drivers , so it is coupled with a linux distro that provides device / hardware access [4]
** the os that the VMM is using for driver's is called the hostOS [6]
*the hostOS provides login and physical access to the hardware as well as management for the VMM [6]
=== VM ===
* the OS that the vm is running is called the guestOS [6]
* the guestOS only sees resources that have been allocated to the VM [6]
==== three approaches ====
*Type I virtualization [5]
** runs off the physical hardware [4]
** Isolation of the guestOs from the hardware is done threw processe level protection meachnism[6]
*** ring 0 = VMM [6]
*** ring 1 = VM [6]
*** this means all instructions from the VM must go threw the VMM [6]
** since there can be multiple VM's on a computer the scheduling is done by the VMM [6]
** on boot the VMM creates a hardware platform for the VM [6]
** load's the VM kernel into virtual memory and then boot's it like a regular computer [6]
** ex. Xen [4]
*Type II virtualization [5]
** run off the host Os [4]
** ex. VMware , QEMU [4]
* Para-virtualization [6]
** Similar to Type but use the HostOs for Device driver access [6]

== Exokernel ==
* Micro-kernel architecture with limited abstractions, ask for resource, get resource not resource abstraction
* Less functionality provided by kernel, security and handling of resource sharing
* Once application receives resource, it can use it as it wishes/in control
* Keep the basic kernel to handle allocating resources and sharing rather than developing straight to the hardware

----
* multiplex resources securely providing protection to mutual distrustful application threw the use of secure binding's[1]
* Goal of the exokernel is to give LibOS maximum freedom with out allowing them to interfere with each other. to do this the exokernel separates protection from management in doing this it provide 3 important tasks[1]
** tracking ownership of resources [1]
** ensuring protection by guarding all resource usage and binding points (not to shure what binding points are)[1]
** revoking access to the resources [1]
* LibrayOS (LibOs)
** Reduces the number of kernel crossings[1]
** Not trusted by the exokernel so can be trusted by the application , Example given is a bad parameter passed to the LibOs only the application is affected.[1] (So LibOs cant interact with kernel ???)
** Any application running on the Exokernel can change the LibrayOs freely [1]
** Application that use LibOS that implement standard interfaces (POSIX) will be portable on any system with the same interface [1]
** LibOs can be made portable if it is designed to interact with a low-level machine independent level to hide hardware details [1]

=== Exokernel Design ===
==== Design Principles ====
*Securely Expose Hardware [1]
** an Exokernel tries to create low level primitives that the hardware resources can be accessed from, this also includes interrupts,exceptions [1]
** the exokernel also export privileged instructions to the LibOS so that traditional OS abstractions can be implemented (eg Process , address pace)[1]
** Exokernels should avoid resource management except when required protection ( allocation , revocation , ownership)[1]
** application based resource management is the best way to build flexible efficient flexible systems [1]
*Expose allocation[1]
** allow LibOs to request physical resources [1]
** resource allocation should not be automatic, the LibOS should participate in every single allocation decision [1]
*Expose Names[1]
** Use physical name's when ever possible[3] (not to sure what physical names are, I think it is as simple as what the hardware is called)--[[User:Asoknack|Asoknack]] 20:27, 9 October 2010 (UTC)
** Physical names capture useful information [3]
*** safer than and less resource intensive than virtual names as no translations are needed[3]
*Expose Revocation [1]
** use visible revocation protocol [1]
** allows well behaved LibOS to preform application level resource management [1]
** Visible revocation allows the LibOS to choose what instance of the resource to release[1](Visible means that when revocation happens the exokernel tell the LibOS that resource is being revoked)
''' Policy '''
* LibOS handle resource policy decisions
* Exokernels have a policy to decided between competing LibOS (Priority , share of resources)
** it enforces this threw allocation and deallocation (every thing can achieved threw this even what block to write and such)

==== Secure Bindings ====
* Used by the exokernel to allow the LibOS to bind to resources [1]
* Allows the separation of protection and resource use [1]
* only checks authorization during bind time [1]
** Application's with complex needs for resources only authorized during bind.[1]
* access checking is done during access time and there is no need to understand complex resources needs during access[1]
** (this means that the exokernel checks once to make sure an application has authorization once approved, when the application tries to use the resource the exokernel is only concerned about policy conflict's)--[[User:Asoknack|Asoknack]] 18:20, 9 October 2010 (UTC)
** allows the kernel to protect the resources with out understanding what the resource is [1]
*three way's to implement
* Hardware Mechanisms [1]
* Software caching [1]
* Downloading application code [1]
''' Downloading Code to the Kernel '''
* used to implement secure bindings , and improve performance[1]
** eliminate the number of kernel crossings [1]
** downloaded code can be run with out the application to be scheduled [2]
==== Visible Resource Revocation ====
* Used for most resources [1]
** allows for LibOS to help with deallocation [1]
** LibOS are able to garner what resources are scare [1]
* Slower than Invisible as application involvement is required [1]
** ex of when invisible is used is Processor addressing-context identifiers [1]
==== Abort Protocol ====
* allows the exokernel to take resources away from the LibOS [1]
* used when the LibOS fails to respond to the revocation request [1]
* Exokernel must be careful not to delete as the LibOS might need to write some system critical data to the resource [1]

== Comparisons ==
====Exokernel/Microkernel====
'''Similarities'''
* Limited functionality in kernel
** functionality in kernel to handle sharing of resources and security
** avoids programming directly to hardware which creates a dependency
* Additional functionality provided in user space as processes
'''Differences'''
* Minimal abstractions provided by the kernel
** Applications given more power in exokernel

====Exokernel/VM====
'''Similarities'''
* Idea of partitioning resources between applications/OSs
* "Control" of resource given
* Isolation from other applications/OSs
'''Differences'''
* Exokernel runs applications, VM runs OS
* VM uses a hostOS and guestOSs run on top
* Virtualization on VMs, Exokernel deals with real resources
* VM hides a lot of information because it emulates. Exokernel does not.

====Microkernel/VM====
'''Differences'''
* With a virtual machine, you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System.
* This can be costly but the benefits are that it's easier and all the standard OS features are available.

== References ==
[1]<nowiki> Engler, D. R., Kaashoek, M. F., and O'Toole, J. 1995. Exokernel: an operating system architecture for application-level resource management. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 251-266. DOI= http://doi.acm.org/10.1145/224056.224076 </nowiki>

[2]<nowiki>Engler, Dawson R. "The Exokernel Operating System Architecture." Diss. Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 1998. Web. 9 Oct. 2010. <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5054&rep=rep1&type=pdf>.</nowiki>

[3]<nowiki>Kaashoek, M. F., Engler, D. R., Ganger, G. R., Briceño, H. M., Hunt, R., Mazières, D., Pinckney, T., Grimm, R., Jannotti, J., and Mackenzie, K. 1997. Application performance and flexibility on exokernel systems. In Proceedings of the Sixteenth ACM Symposium on Operating Systems Principles (Saint Malo, France, October 05 - 08, 1997). W. M. Waite, Ed. SOSP '97. ACM, New York, NY, 52-65. DOI= http://doi.acm.org/10.1145/268998.266644 </nowiki>

[4]<nowiki>Vallee, G.; Naughton, T.; Engelmann, C.; Hong Ong; Scott, S.L.; , "System-Level Virtualization for High Performance Computing," Parallel, Distributed and Network-Based Processing, 2008. PDP 2008. 16th Euromicro Conference on , vol., no., pp.636-643, 13-15 Feb. 2008
DOI= http://doi.acm.org/10.1109/PDP.2008.85 </nowiki>

[5]<nowiki>Goldberg, R. P. 1973. Architecture of virtual machines. In Proceedings of the Workshop on Virtual Computer Systems (Cambridge, Massachusetts, United States, March 26 - 27, 1973). ACM, New York, NY, 74-112. DOI= http://doi.acm.org/10.1145/800122.803950 </nowiki>

[6]<nowiki>Vallee, G., Naughton, T., and Scott, S. L. 2007. System management software for virtual environments. In Proceedings of the 4th international Conference on Computing Frontiers (Ischia, Italy, May 07 - 09, 2007). CF '07. ACM, New York, NY, 153-160. DOI= http://doi.acm.org/10.1145/1242531.1242555 </nowiki>

[7]<nowiki>Liedtke, J. 1995. On micro-kernel construction. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 237-250. DOI= http://doi.acm.org/10.1145/224056.224075 </nowiki>

== Unsorted ==
An overview of exokernels,virtual machines, microkernels *[http://www2.supchurch.org:10999/files/school/classes/CSCI4730/Lectures/grad-structures.ppt Overview](Power Point) 
Should not be used as a source but an overview.

The original paper on [http://portal.acm.org/citation.cfm?id=224076 Exokernels] --[[User:Gautam|Gautam]] 22:39, 6 October 2010 (UTC)

Exokernel-
Minimalistic abstractions for developers
Exokernels can be seen as a good compromise between virtual machines and microkernels in the sense that exokernels can give that low level access to developers similar to direct access through a protected layer and at the same time can contain enough hardware abstraction to allow similar benefit of hiding the hardware resources to application programs.
Exokernel – fewest hardware abstractions to developer
Microkernel - is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system
Virtual machine is a simulation of any or devices requested by an application program
Exokenel – I’ve got a sound card
Virtual Machine – I’ve got the sound card you’re looking for, perfect virtual match
Microkernel – I’ve got sound card that plays Khazikstan sound format only
MicroKernel - Very small, very predictable, good for schedualing (QNX is a microkernel - POSIX compatable, benefits of running linux software like modern browsers)

This is some ideas I've got on this question, please contribute below
-Rovic

Outlining some main features here as I see them.

I found that the exokernel was an even lower-level design than the microkernel, closer to the hardware without abstraction. They have the same architecture with the basic functionality contained in the kernel to manage everyone. As the exokernel "gives" the resource to the application it can use the resource in isolation of other applications (until forced to shared) much like VMs receive their resources, either partitioned or virtualized, and execute as if its running on its own machine. There is this similar notion of partitioning the resources among applications/OS and allowing them to take control of what they have.

I'll locate some references later on. --[[User:Slay|Slay]] 15:00, 7 October 2010 (UTC)

I'm just going to post my answer for question 1 on the individuel assignment and hope it helps. --[[User:Aellebla|Aellebla]] 15:06, 12 October 2010 (UTC)

The design of the micro kernel was to take everything they could out of the Kernel and put it into a process. For ex, networking would be put into a process instead of staying in the kernel. The micro kernel dev's tried to keep lots of things in user space for efficiency. But one major problem with this is there would be a large amount of moving from a process to the kernel to user space and back again and this is a costly, non efficient process.It was an application specific OS, there was no multiplexing. With a virtual machine you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System. This is very heavy however but the benefits are that it‟s easy and all the standard OS features are there whereas in a microkernel setup they would not all be there and this can be seen as a compromise.

Exokernels can be seen as a compromise to virtual machines and microkernels because virtual machines emulate and exokernels do not. When you emulate something you hide a lot of the actual information because you wouldn‟t be able to see the „real‟ hardware. If we look at a virtual box setup running Linux, and we go look at all the hardware, it will be displayed as fake hardware.

Maybe we can have an introduction - paragraph or so on each type - then similarities - differences - and the compromise. I am going to do some research and writing this weekend and I will put some up -- Jslonosky

btw in my page (i guess you can call it that) i have some resources i have found --[[User:Asoknack|Asoknack]] 15:50, 8 October 2010 (UTC)
- Wow, nice man. I will go ahead and write up the descriptive paragraphs on each kernel and virtual machine if no one minds. --Jslonosky

I think we should divide up the paragraphs and proofread each others instead. (Are there only 4 of us?) I don't have much time to work on this today though but I'll try to work on it tomorrow morning. - Slay

Sure guy. That sounds good. There should be 5 or 6 of us though.. . Oh well. Their loss. I will do some before or after work today. Ill start with Microkernel since there is not a large amount of info here, and so we don't overlap each other - JSlonosky

yeah i think there was more like 7 of us btw if any one has any more information feel free to add it would be nice if you add the references so that way citing is really easy on acm.org it will auto give you the citation info (where it says Display Formats click on ACM Ref and new window with the citation info auto pop's up) --[[User:Asoknack|Asoknack]] 02:28, 11 October 2010 (UTC)

I added an outline of the similarities and differences. Add any more that I missed. These are from observations so I don't have any resources. -Slay
That's probably fine. Our textbook probably outlines some of them, so I am sure we can find a few there - JSlonosky

Talked to the teacher today and for VM he said we should focus on the implementation such as Xen and VMware , he also said to talk about para virtualization --[[User:Asoknack|Asoknack]] 18:42, 12 October 2010 (UTC)

== The Essay ==

Let's actually breakdown the essay into components then write it here.

We have our intro/thesis statement

...to the extent that exokernels be seen as a compromise between virtual machines and microkernels.
-I'll work on the initial intro, should have it ready by tonight. -Slade

3 paragraphs that prove it
Explain how the key design characteristics of these three system architectures compare with each other.

and conclusion

COMP 3000 Essay 1 2010 Question 1

2010-10-12T19:13:48Z

Asoknack: /* Resources */

=Question=
To what extent can exokernels be seen as a compromise between virtual machines and microkernels? Explain how the key design characteristics of these three system architectures compare with each other.

=Answer=

=Misc=
* every thing is moved to discussion page

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-12T19:10:34Z

Asoknack: /* Address Space */

== Microkernel ==
* Moving kernel functionality into processes contained in user space, e.g. file systems, drivers
* Keep basic functionality in kernel to handle sharing of resources
* Separation allows for manageability and security, corruption in one does not necessarily cause failure in system
* Large amount of moving from a process to Kernel to user space and back again, this is a costly operation.

----

''' Microkernel '''
* try's to minimize the amount of software that is mandatory or required [7]
advantages of Microkernel
* favors a modular system structure [7]
* one failure of a program does not impact any other programs [7]
* can support more than one api or strategies since all programs are separated [7]
==== Microkernel Concepts ====
* piece of code is allowed in the kernel only if moving it outside the kernel would adversely affect the system. [7]
* any subsystem program created must be independent of all other subsystem's, any subsystem that is used can guarantee this from all other subsystems [7]
===== Address Space =====
* a mapping that relates the physical page to the virtual page. [7]
* hide's the hardware's concept of address space [7]
* based off the idea of recursion each subsystem has it's own address space [7]
* the micro kernel provides 3 operations [7]
** Grant [7]
*** allows the owner to give a page to a recipient, provided the recipient want's it the page is removed from the owner's address space and but in the recipients. [7]
*** must be available to the owner. [7]
** Map [7]
*** allows the user to share a page with a recipient [7]
*** page is not removed from the owner's address space. [7]
** Flush [7]
*** remove's the page from all recipients address space
*** how does this work with Grant --[[User:Asoknack|Asoknack]] 19:10, 12 October 2010 (UTC)

===== Thread's IPC =====
===== Unique Identifiers =====

== Virtual Machine ==
* Partitioning or virtualizing resources among OS virtualization running on top of host OS
* Virtualized OS believe running on full machine on its own

----
System Level Virtualization

=== VMM ===
* stands for Virtual Machine Monitor, also known as the hyper-visor[4]
* responsible for virtualization of hardware(mapping physical to virtual) and the VM that run on top of the virtuallized hardware [4]
* usually a small os with no drivers , so it is coupled with a linux distro that provides device / hardware access [4]
** the os that the VMM is using for driver's is called the hostOS [6]
*the hostOS provides login and physical access to the hardware as well as management for the VMM [6]
=== VM ===
* the OS that the vm is running is called the guestOS [6]
* the guestOS only sees resources that have been allocated to the VM [6]
==== three approaches ====
*Type I virtualization [5]
** runs off the physical hardware [4]
** Isolation of the guestOs from the hardware is done threw processe level protection meachnism[6]
*** ring 0 = VMM [6]
*** ring 1 = VM [6]
*** this means all instructions from the VM must go threw the VMM [6]
** since there can be multiple VM's on a computer the scheduling is done by the VMM [6]
** on boot the VMM creates a hardware platform for the VM [6]
** load's the VM kernel into virtual memory and then boot's it like a regular computer [6]
** ex. Xen [4]
*Type II virtualization [5]
** run off the host Os [4]
** ex. VMware , QEMU [4]
* Para-virtualization [6]
** Similar to Type but use the HostOs for Device driver access [6]

== Exokernel ==
* Micro-kernel architecture with limited abstractions, ask for resource, get resource not resource abstraction
* Less functionality provided by kernel, security and handling of resource sharing
* Once application receives resource, it can use it as it wishes/in control
* Keep the basic kernel to handle allocating resources and sharing rather than developing straight to the hardware

----
* multiplex resources securely providing protection to mutual distrustful application threw the use of secure binding's[1]
* Goal of the exokernel is to give LibOS maximum freedom with out allowing them to interfere with each other. to do this the exokernel separates protection from management in doing this it provide 3 important tasks[1]
** tracking ownership of resources [1]
** ensuring protection by guarding all resource usage and binding points (not to shure what binding points are)[1]
** revoking access to the resources [1]
* LibrayOS (LibOs)
** Reduces the number of kernel crossings[1]
** Not trusted by the exokernel so can be trusted by the application , Example given is a bad parameter passed to the LibOs only the application is affected.[1] (So LibOs cant interact with kernel ???)
** Any application running on the Exokernel can change the LibrayOs freely [1]
** Application that use LibOS that implement standard interfaces (POSIX) will be portable on any system with the same interface [1]
** LibOs can be made portable if it is designed to interact with a low-level machine independent level to hide hardware details [1]

=== Exokernel Design ===
==== Design Principles ====
*Securely Expose Hardware [1]
** an Exokernel tries to create low level primitives that the hardware resources can be accessed from, this also includes interrupts,exceptions [1]
** the exokernel also export privileged instructions to the LibOS so that traditional OS abstractions can be implemented (eg Process , address pace)[1]
** Exokernels should avoid resource management except when required protection ( allocation , revocation , ownership)[1]
** application based resource management is the best way to build flexible efficient flexible systems [1]
*Expose allocation[1]
** allow LibOs to request physical resources [1]
** resource allocation should not be automatic, the LibOS should participate in every single allocation decision [1]
*Expose Names[1]
** Use physical name's when ever possible[3] (not to sure what physical names are, I think it is as simple as what the hardware is called)--[[User:Asoknack|Asoknack]] 20:27, 9 October 2010 (UTC)
** Physical names capture useful information [3]
*** safer than and less resource intensive than virtual names as no translations are needed[3]
*Expose Revocation [1]
** use visible revocation protocol [1]
** allows well behaved LibOS to preform application level resource management [1]
** Visible revocation allows the LibOS to choose what instance of the resource to release[1](Visible means that when revocation happens the exokernel tell the LibOS that resource is being revoked)
''' Policy '''
* LibOS handle resource policy decisions
* Exokernels have a policy to decided between competing LibOS (Priority , share of resources)
** it enforces this threw allocation and deallocation (every thing can achieved threw this even what block to write and such)

==== Secure Bindings ====
* Used by the exokernel to allow the LibOS to bind to resources [1]
* Allows the separation of protection and resource use [1]
* only checks authorization during bind time [1]
** Application's with complex needs for resources only authorized during bind.[1]
* access checking is done during access time and there is no need to understand complex resources needs during access[1]
** (this means that the exokernel checks once to make sure an application has authorization once approved, when the application tries to use the resource the exokernel is only concerned about policy conflict's)--[[User:Asoknack|Asoknack]] 18:20, 9 October 2010 (UTC)
** allows the kernel to protect the resources with out understanding what the resource is [1]
*three way's to implement
* Hardware Mechanisms [1]
* Software caching [1]
* Downloading application code [1]
''' Downloading Code to the Kernel '''
* used to implement secure bindings , and improve performance[1]
** eliminate the number of kernel crossings [1]
** downloaded code can be run with out the application to be scheduled [2]
==== Visible Resource Revocation ====
* Used for most resources [1]
** allows for LibOS to help with deallocation [1]
** LibOS are able to garner what resources are scare [1]
* Slower than Invisible as application involvement is required [1]
** ex of when invisible is used is Processor addressing-context identifiers [1]
==== Abort Protocol ====
* allows the exokernel to take resources away from the LibOS [1]
* used when the LibOS fails to respond to the revocation request [1]
* Exokernel must be careful not to delete as the LibOS might need to write some system critical data to the resource [1]

== Comparisons ==
====Exokernel/Microkernel====
'''Similarities'''
* Limited functionality in kernel
** functionality in kernel to handle sharing of resources and security
** avoids programming directly to hardware which creates a dependency
* Additional functionality provided in user space as processes
'''Differences'''
* Minimal abstractions provided by the kernel
** Applications given more power in exokernel

====Exokernel/VM====
'''Similarities'''
* Idea of partitioning resources between applications/OSs
* "Control" of resource given
* Isolation from other applications/OSs
'''Differences'''
* Exokernel runs applications, VM runs OS
* VM uses a hostOS and guestOSs run on top
* Virtualization on VMs, Exokernel deals with real resources
* VM hides a lot of information because it emulates. Exokernel does not.

====Microkernel/VM====
'''Differences'''
* With a virtual machine, you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System.
* This can be costly but the benefits are that it's easier and all the standard OS features are available.

== References ==
[1]<nowiki> Engler, D. R., Kaashoek, M. F., and O'Toole, J. 1995. Exokernel: an operating system architecture for application-level resource management. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 251-266. DOI= http://doi.acm.org/10.1145/224056.224076 </nowiki>

[2]<nowiki>Engler, Dawson R. "The Exokernel Operating System Architecture." Diss. Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 1998. Web. 9 Oct. 2010. <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5054&rep=rep1&type=pdf>.</nowiki>

[3]<nowiki>Kaashoek, M. F., Engler, D. R., Ganger, G. R., Briceño, H. M., Hunt, R., Mazières, D., Pinckney, T., Grimm, R., Jannotti, J., and Mackenzie, K. 1997. Application performance and flexibility on exokernel systems. In Proceedings of the Sixteenth ACM Symposium on Operating Systems Principles (Saint Malo, France, October 05 - 08, 1997). W. M. Waite, Ed. SOSP '97. ACM, New York, NY, 52-65. DOI= http://doi.acm.org/10.1145/268998.266644 </nowiki>

[4]<nowiki>Vallee, G.; Naughton, T.; Engelmann, C.; Hong Ong; Scott, S.L.; , "System-Level Virtualization for High Performance Computing," Parallel, Distributed and Network-Based Processing, 2008. PDP 2008. 16th Euromicro Conference on , vol., no., pp.636-643, 13-15 Feb. 2008
DOI= http://doi.acm.org/10.1109/PDP.2008.85 </nowiki>

[5]<nowiki>Goldberg, R. P. 1973. Architecture of virtual machines. In Proceedings of the Workshop on Virtual Computer Systems (Cambridge, Massachusetts, United States, March 26 - 27, 1973). ACM, New York, NY, 74-112. DOI= http://doi.acm.org/10.1145/800122.803950 </nowiki>

[6]<nowiki>Vallee, G., Naughton, T., and Scott, S. L. 2007. System management software for virtual environments. In Proceedings of the 4th international Conference on Computing Frontiers (Ischia, Italy, May 07 - 09, 2007). CF '07. ACM, New York, NY, 153-160. DOI= http://doi.acm.org/10.1145/1242531.1242555 </nowiki>

[7]<nowiki>Liedtke, J. 1995. On micro-kernel construction. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 237-250. DOI= http://doi.acm.org/10.1145/224056.224075 </nowiki>

== Unsorted ==
Exokernel-
Minimalistic abstractions for developers
Exokernels can be seen as a good compromise between virtual machines and microkernels in the sense that exokernels can give that low level access to developers similar to direct access through a protected layer and at the same time can contain enough hardware abstraction to allow similar benefit of hiding the hardware resources to application programs.
Exokernel – fewest hardware abstractions to developer
Microkernel - is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system
Virtual machine is a simulation of any or devices requested by an application program
Exokenel – I’ve got a sound card
Virtual Machine – I’ve got the sound card you’re looking for, perfect virtual match
Microkernel – I’ve got sound card that plays Khazikstan sound format only
MicroKernel - Very small, very predictable, good for schedualing (QNX is a microkernel - POSIX compatable, benefits of running linux software like modern browsers)

This is some ideas I've got on this question, please contribute below
-Rovic

Outlining some main features here as I see them.

I found that the exokernel was an even lower-level design than the microkernel, closer to the hardware without abstraction. They have the same architecture with the basic functionality contained in the kernel to manage everyone. As the exokernel "gives" the resource to the application it can use the resource in isolation of other applications (until forced to shared) much like VMs receive their resources, either partitioned or virtualized, and execute as if its running on its own machine. There is this similar notion of partitioning the resources among applications/OS and allowing them to take control of what they have.

I'll locate some references later on. --[[User:Slay|Slay]] 15:00, 7 October 2010 (UTC)

I'm just going to post my answer for question 1 on the individuel assignment and hope it helps. --[[User:Aellebla|Aellebla]] 15:06, 12 October 2010 (UTC)

The design of the micro kernel was to take everything they could out of the Kernel and put it into a process. For ex, networking would be put into a process instead of staying in the kernel. The micro kernel dev's tried to keep lots of things in user space for efficiency. But one major problem with this is there would be a large amount of moving from a process to the kernel to user space and back again and this is a costly, non efficient process.It was an application specific OS, there was no multiplexing. With a virtual machine you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System. This is very heavy however but the benefits are that it‟s easy and all the standard OS features are there whereas in a microkernel setup they would not all be there and this can be seen as a compromise.

Exokernels can be seen as a compromise to virtual machines and microkernels because virtual machines emulate and exokernels do not. When you emulate something you hide a lot of the actual information because you wouldn‟t be able to see the „real‟ hardware. If we look at a virtual box setup running Linux, and we go look at all the hardware, it will be displayed as fake hardware.

Maybe we can have an introduction - paragraph or so on each type - then similarities - differences - and the compromise. I am going to do some research and writing this weekend and I will put some up -- Jslonosky

btw in my page (i guess you can call it that) i have some resources i have found --[[User:Asoknack|Asoknack]] 15:50, 8 October 2010 (UTC)
- Wow, nice man. I will go ahead and write up the descriptive paragraphs on each kernel and virtual machine if no one minds. --Jslonosky

I think we should divide up the paragraphs and proofread each others instead. (Are there only 4 of us?) I don't have much time to work on this today though but I'll try to work on it tomorrow morning. - Slay

Sure guy. That sounds good. There should be 5 or 6 of us though.. . Oh well. Their loss. I will do some before or after work today. Ill start with Microkernel since there is not a large amount of info here, and so we don't overlap each other - JSlonosky

yeah i think there was more like 7 of us btw if any one has any more information feel free to add it would be nice if you add the references so that way citing is really easy on acm.org it will auto give you the citation info (where it says Display Formats click on ACM Ref and new window with the citation info auto pop's up) --[[User:Asoknack|Asoknack]] 02:28, 11 October 2010 (UTC)

I added an outline of the similarities and differences. Add any more that I missed. These are from observations so I don't have any resources. -Slay
That's probably fine. Our textbook probably outlines some of them, so I am sure we can find a few there - JSlonosky

Talked to the teacher today and for VM he said we should focus on the implementation such as Xen and VMware , he also said to talk about para virtualization --[[User:Asoknack|Asoknack]] 18:42, 12 October 2010 (UTC)

== The Essay ==

Let's actually breakdown the essay into components then write it here.

We have our intro/thesis statement

...to the extent that exokernels be seen as a compromise between virtual machines and microkernels.
-I'll work on the initial intro, should have it ready by tonight. -Slade

3 paragraphs that prove it
Explain how the key design characteristics of these three system architectures compare with each other.

and conclusion

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-12T18:57:25Z

Asoknack: /* Microkernel */

== Microkernel ==
* Moving kernel functionality into processes contained in user space, e.g. file systems, drivers
* Keep basic functionality in kernel to handle sharing of resources
* Separation allows for manageability and security, corruption in one does not necessarily cause failure in system
* Large amount of moving from a process to Kernel to user space and back again, this is a costly operation.

----

''' Microkernel '''
* try's to minimize the amount of software that is mandatory or required [7]
advantages of Microkernel
* favors a modular system structure [7]
* one failure of a program does not impact any other programs [7]
* can support more than one api or strategies since all programs are separated [7]
==== Microkernel Concepts ====
* piece of code is allowed in the kernel only if moving it outside the kernel would adversely affect the system. [7]
* any subsystem program created must be independent of all other subsystem's, any subsystem that is used can guarantee this from all other subsystems [7]
===== Address Space =====
* a mapping that relates the physical page to the virtual page. [7]
* hide's the hardware's concept of address space [7]
* the micro kernel provides 3 operations [7]
** Grant [7]
** Map [7]
** Flush [7]
===== Thread's IPC =====
===== Unique Identifiers =====

== Virtual Machine ==
* Partitioning or virtualizing resources among OS virtualization running on top of host OS
* Virtualized OS believe running on full machine on its own

----
System Level Virtualization

=== VMM ===
* stands for Virtual Machine Monitor, also known as the hyper-visor[4]
* responsible for virtualization of hardware(mapping physical to virtual) and the VM that run on top of the virtuallized hardware [4]
* usually a small os with no drivers , so it is coupled with a linux distro that provides device / hardware access [4]
** the os that the VMM is using for driver's is called the hostOS [6]
*the hostOS provides login and physical access to the hardware as well as management for the VMM [6]
=== VM ===
* the OS that the vm is running is called the guestOS [6]
* the guestOS only sees resources that have been allocated to the VM [6]
==== three approaches ====
*Type I virtualization [5]
** runs off the physical hardware [4]
** Isolation of the guestOs from the hardware is done threw processe level protection meachnism[6]
*** ring 0 = VMM [6]
*** ring 1 = VM [6]
*** this means all instructions from the VM must go threw the VMM [6]
** since there can be multiple VM's on a computer the scheduling is done by the VMM [6]
** on boot the VMM creates a hardware platform for the VM [6]
** load's the VM kernel into virtual memory and then boot's it like a regular computer [6]
** ex. Xen [4]
*Type II virtualization [5]
** run off the host Os [4]
** ex. VMware , QEMU [4]
* Para-virtualization [6]
** Similar to Type but use the HostOs for Device driver access [6]

== Exokernel ==
* Micro-kernel architecture with limited abstractions, ask for resource, get resource not resource abstraction
* Less functionality provided by kernel, security and handling of resource sharing
* Once application receives resource, it can use it as it wishes/in control
* Keep the basic kernel to handle allocating resources and sharing rather than developing straight to the hardware

----
* multiplex resources securely providing protection to mutual distrustful application threw the use of secure binding's[1]
* Goal of the exokernel is to give LibOS maximum freedom with out allowing them to interfere with each other. to do this the exokernel separates protection from management in doing this it provide 3 important tasks[1]
** tracking ownership of resources [1]
** ensuring protection by guarding all resource usage and binding points (not to shure what binding points are)[1]
** revoking access to the resources [1]
* LibrayOS (LibOs)
** Reduces the number of kernel crossings[1]
** Not trusted by the exokernel so can be trusted by the application , Example given is a bad parameter passed to the LibOs only the application is affected.[1] (So LibOs cant interact with kernel ???)
** Any application running on the Exokernel can change the LibrayOs freely [1]
** Application that use LibOS that implement standard interfaces (POSIX) will be portable on any system with the same interface [1]
** LibOs can be made portable if it is designed to interact with a low-level machine independent level to hide hardware details [1]

=== Exokernel Design ===
==== Design Principles ====
*Securely Expose Hardware [1]
** an Exokernel tries to create low level primitives that the hardware resources can be accessed from, this also includes interrupts,exceptions [1]
** the exokernel also export privileged instructions to the LibOS so that traditional OS abstractions can be implemented (eg Process , address pace)[1]
** Exokernels should avoid resource management except when required protection ( allocation , revocation , ownership)[1]
** application based resource management is the best way to build flexible efficient flexible systems [1]
*Expose allocation[1]
** allow LibOs to request physical resources [1]
** resource allocation should not be automatic, the LibOS should participate in every single allocation decision [1]
*Expose Names[1]
** Use physical name's when ever possible[3] (not to sure what physical names are, I think it is as simple as what the hardware is called)--[[User:Asoknack|Asoknack]] 20:27, 9 October 2010 (UTC)
** Physical names capture useful information [3]
*** safer than and less resource intensive than virtual names as no translations are needed[3]
*Expose Revocation [1]
** use visible revocation protocol [1]
** allows well behaved LibOS to preform application level resource management [1]
** Visible revocation allows the LibOS to choose what instance of the resource to release[1](Visible means that when revocation happens the exokernel tell the LibOS that resource is being revoked)
''' Policy '''
* LibOS handle resource policy decisions
* Exokernels have a policy to decided between competing LibOS (Priority , share of resources)
** it enforces this threw allocation and deallocation (every thing can achieved threw this even what block to write and such)

==== Secure Bindings ====
* Used by the exokernel to allow the LibOS to bind to resources [1]
* Allows the separation of protection and resource use [1]
* only checks authorization during bind time [1]
** Application's with complex needs for resources only authorized during bind.[1]
* access checking is done during access time and there is no need to understand complex resources needs during access[1]
** (this means that the exokernel checks once to make sure an application has authorization once approved, when the application tries to use the resource the exokernel is only concerned about policy conflict's)--[[User:Asoknack|Asoknack]] 18:20, 9 October 2010 (UTC)
** allows the kernel to protect the resources with out understanding what the resource is [1]
*three way's to implement
* Hardware Mechanisms [1]
* Software caching [1]
* Downloading application code [1]
''' Downloading Code to the Kernel '''
* used to implement secure bindings , and improve performance[1]
** eliminate the number of kernel crossings [1]
** downloaded code can be run with out the application to be scheduled [2]
==== Visible Resource Revocation ====
* Used for most resources [1]
** allows for LibOS to help with deallocation [1]
** LibOS are able to garner what resources are scare [1]
* Slower than Invisible as application involvement is required [1]
** ex of when invisible is used is Processor addressing-context identifiers [1]
==== Abort Protocol ====
* allows the exokernel to take resources away from the LibOS [1]
* used when the LibOS fails to respond to the revocation request [1]
* Exokernel must be careful not to delete as the LibOS might need to write some system critical data to the resource [1]

== Comparisons ==
====Exokernel/Microkernel====
'''Similarities'''
* Limited functionality in kernel
** functionality in kernel to handle sharing of resources and security
** avoids programming directly to hardware which creates a dependency
* Additional functionality provided in user space as processes
'''Differences'''
* Minimal abstractions provided by the kernel
** Applications given more power in exokernel

====Exokernel/VM====
'''Similarities'''
* Idea of partitioning resources between applications/OSs
* "Control" of resource given
* Isolation from other applications/OSs
'''Differences'''
* Exokernel runs applications, VM runs OS
* VM uses a hostOS and guestOSs run on top
* Virtualization on VMs, Exokernel deals with real resources
* VM hides a lot of information because it emulates. Exokernel does not.

====Microkernel/VM====
'''Differences'''
* With a virtual machine, you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System.
* This can be costly but the benefits are that it's easier and all the standard OS features are available.

== References ==
[1]<nowiki> Engler, D. R., Kaashoek, M. F., and O'Toole, J. 1995. Exokernel: an operating system architecture for application-level resource management. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 251-266. DOI= http://doi.acm.org/10.1145/224056.224076 </nowiki>

[2]<nowiki>Engler, Dawson R. "The Exokernel Operating System Architecture." Diss. Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 1998. Web. 9 Oct. 2010. <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5054&rep=rep1&type=pdf>.</nowiki>

[3]<nowiki>Kaashoek, M. F., Engler, D. R., Ganger, G. R., Briceño, H. M., Hunt, R., Mazières, D., Pinckney, T., Grimm, R., Jannotti, J., and Mackenzie, K. 1997. Application performance and flexibility on exokernel systems. In Proceedings of the Sixteenth ACM Symposium on Operating Systems Principles (Saint Malo, France, October 05 - 08, 1997). W. M. Waite, Ed. SOSP '97. ACM, New York, NY, 52-65. DOI= http://doi.acm.org/10.1145/268998.266644 </nowiki>

[4]<nowiki>Vallee, G.; Naughton, T.; Engelmann, C.; Hong Ong; Scott, S.L.; , "System-Level Virtualization for High Performance Computing," Parallel, Distributed and Network-Based Processing, 2008. PDP 2008. 16th Euromicro Conference on , vol., no., pp.636-643, 13-15 Feb. 2008
DOI= http://doi.acm.org/10.1109/PDP.2008.85 </nowiki>

[5]<nowiki>Goldberg, R. P. 1973. Architecture of virtual machines. In Proceedings of the Workshop on Virtual Computer Systems (Cambridge, Massachusetts, United States, March 26 - 27, 1973). ACM, New York, NY, 74-112. DOI= http://doi.acm.org/10.1145/800122.803950 </nowiki>

[6]<nowiki>Vallee, G., Naughton, T., and Scott, S. L. 2007. System management software for virtual environments. In Proceedings of the 4th international Conference on Computing Frontiers (Ischia, Italy, May 07 - 09, 2007). CF '07. ACM, New York, NY, 153-160. DOI= http://doi.acm.org/10.1145/1242531.1242555 </nowiki>

[7]<nowiki>Liedtke, J. 1995. On micro-kernel construction. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 237-250. DOI= http://doi.acm.org/10.1145/224056.224075 </nowiki>

== Unsorted ==
Exokernel-
Minimalistic abstractions for developers
Exokernels can be seen as a good compromise between virtual machines and microkernels in the sense that exokernels can give that low level access to developers similar to direct access through a protected layer and at the same time can contain enough hardware abstraction to allow similar benefit of hiding the hardware resources to application programs.
Exokernel – fewest hardware abstractions to developer
Microkernel - is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system
Virtual machine is a simulation of any or devices requested by an application program
Exokenel – I’ve got a sound card
Virtual Machine – I’ve got the sound card you’re looking for, perfect virtual match
Microkernel – I’ve got sound card that plays Khazikstan sound format only
MicroKernel - Very small, very predictable, good for schedualing (QNX is a microkernel - POSIX compatable, benefits of running linux software like modern browsers)

This is some ideas I've got on this question, please contribute below
-Rovic

Outlining some main features here as I see them.

I found that the exokernel was an even lower-level design than the microkernel, closer to the hardware without abstraction. They have the same architecture with the basic functionality contained in the kernel to manage everyone. As the exokernel "gives" the resource to the application it can use the resource in isolation of other applications (until forced to shared) much like VMs receive their resources, either partitioned or virtualized, and execute as if its running on its own machine. There is this similar notion of partitioning the resources among applications/OS and allowing them to take control of what they have.

I'll locate some references later on. --[[User:Slay|Slay]] 15:00, 7 October 2010 (UTC)

I'm just going to post my answer for question 1 on the individuel assignment and hope it helps. --[[User:Aellebla|Aellebla]] 15:06, 12 October 2010 (UTC)

The design of the micro kernel was to take everything they could out of the Kernel and put it into a process. For ex, networking would be put into a process instead of staying in the kernel. The micro kernel dev's tried to keep lots of things in user space for efficiency. But one major problem with this is there would be a large amount of moving from a process to the kernel to user space and back again and this is a costly, non efficient process.It was an application specific OS, there was no multiplexing. With a virtual machine you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System. This is very heavy however but the benefits are that it‟s easy and all the standard OS features are there whereas in a microkernel setup they would not all be there and this can be seen as a compromise.

Exokernels can be seen as a compromise to virtual machines and microkernels because virtual machines emulate and exokernels do not. When you emulate something you hide a lot of the actual information because you wouldn‟t be able to see the „real‟ hardware. If we look at a virtual box setup running Linux, and we go look at all the hardware, it will be displayed as fake hardware.

Maybe we can have an introduction - paragraph or so on each type - then similarities - differences - and the compromise. I am going to do some research and writing this weekend and I will put some up -- Jslonosky

btw in my page (i guess you can call it that) i have some resources i have found --[[User:Asoknack|Asoknack]] 15:50, 8 October 2010 (UTC)
- Wow, nice man. I will go ahead and write up the descriptive paragraphs on each kernel and virtual machine if no one minds. --Jslonosky

I think we should divide up the paragraphs and proofread each others instead. (Are there only 4 of us?) I don't have much time to work on this today though but I'll try to work on it tomorrow morning. - Slay

Sure guy. That sounds good. There should be 5 or 6 of us though.. . Oh well. Their loss. I will do some before or after work today. Ill start with Microkernel since there is not a large amount of info here, and so we don't overlap each other - JSlonosky

yeah i think there was more like 7 of us btw if any one has any more information feel free to add it would be nice if you add the references so that way citing is really easy on acm.org it will auto give you the citation info (where it says Display Formats click on ACM Ref and new window with the citation info auto pop's up) --[[User:Asoknack|Asoknack]] 02:28, 11 October 2010 (UTC)

I added an outline of the similarities and differences. Add any more that I missed. These are from observations so I don't have any resources. -Slay
That's probably fine. Our textbook probably outlines some of them, so I am sure we can find a few there - JSlonosky

Talked to the teacher today and for VM he said we should focus on the implementation such as Xen and VMware , he also said to talk about para virtualization --[[User:Asoknack|Asoknack]] 18:42, 12 October 2010 (UTC)

== The Essay ==

Let's actually breakdown the essay into components then write it here.

We have our intro/thesis statement

...to the extent that exokernels be seen as a compromise between virtual machines and microkernels.
-I'll work on the initial intro, should have it ready by tonight. -Slade

3 paragraphs that prove it
Explain how the key design characteristics of these three system architectures compare with each other.

and conclusion

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-12T18:48:38Z

Asoknack: /* Microkernel */

== Microkernel ==
* Moving kernel functionality into processes contained in user space, e.g. file systems, drivers
* Keep basic functionality in kernel to handle sharing of resources
* Separation allows for manageability and security, corruption in one does not necessarily cause failure in system
* Large amount of moving from a process to Kernel to user space and back again, this is a costly operation.

----

''' Microkernel '''
* try's to minimize the amount of software that is mandatory or required [7]
advantages of Microkernel
* favors a modular system structure [7]
* one failure of a program does not impact any other programs [7]
* can support more than one api or strategies since all programs are separated [7]
* peice of code is allowed in the kernel only if moving it outside the kernel would adversely affect the system. [7]
==== Microkernel Concepts ====
===== Address Space =====
===== Thread's IPC =====
===== Unique Identifiers =====

== Virtual Machine ==
* Partitioning or virtualizing resources among OS virtualization running on top of host OS
* Virtualized OS believe running on full machine on its own

----
System Level Virtualization

=== VMM ===
* stands for Virtual Machine Monitor, also known as the hyper-visor[4]
* responsible for virtualization of hardware(mapping physical to virtual) and the VM that run on top of the virtuallized hardware [4]
* usually a small os with no drivers , so it is coupled with a linux distro that provides device / hardware access [4]
** the os that the VMM is using for driver's is called the hostOS [6]
*the hostOS provides login and physical access to the hardware as well as management for the VMM [6]
=== VM ===
* the OS that the vm is running is called the guestOS [6]
* the guestOS only sees resources that have been allocated to the VM [6]
==== three approaches ====
*Type I virtualization [5]
** runs off the physical hardware [4]
** Isolation of the guestOs from the hardware is done threw processe level protection meachnism[6]
*** ring 0 = VMM [6]
*** ring 1 = VM [6]
*** this means all instructions from the VM must go threw the VMM [6]
** since there can be multiple VM's on a computer the scheduling is done by the VMM [6]
** on boot the VMM creates a hardware platform for the VM [6]
** load's the VM kernel into virtual memory and then boot's it like a regular computer [6]
** ex. Xen [4]
*Type II virtualization [5]
** run off the host Os [4]
** ex. VMware , QEMU [4]
* Para-virtualization [6]
** Similar to Type but use the HostOs for Device driver access [6]

== Exokernel ==
* Micro-kernel architecture with limited abstractions, ask for resource, get resource not resource abstraction
* Less functionality provided by kernel, security and handling of resource sharing
* Once application receives resource, it can use it as it wishes/in control
* Keep the basic kernel to handle allocating resources and sharing rather than developing straight to the hardware

----
* multiplex resources securely providing protection to mutual distrustful application threw the use of secure binding's[1]
* Goal of the exokernel is to give LibOS maximum freedom with out allowing them to interfere with each other. to do this the exokernel separates protection from management in doing this it provide 3 important tasks[1]
** tracking ownership of resources [1]
** ensuring protection by guarding all resource usage and binding points (not to shure what binding points are)[1]
** revoking access to the resources [1]
* LibrayOS (LibOs)
** Reduces the number of kernel crossings[1]
** Not trusted by the exokernel so can be trusted by the application , Example given is a bad parameter passed to the LibOs only the application is affected.[1] (So LibOs cant interact with kernel ???)
** Any application running on the Exokernel can change the LibrayOs freely [1]
** Application that use LibOS that implement standard interfaces (POSIX) will be portable on any system with the same interface [1]
** LibOs can be made portable if it is designed to interact with a low-level machine independent level to hide hardware details [1]

=== Exokernel Design ===
==== Design Principles ====
*Securely Expose Hardware [1]
** an Exokernel tries to create low level primitives that the hardware resources can be accessed from, this also includes interrupts,exceptions [1]
** the exokernel also export privileged instructions to the LibOS so that traditional OS abstractions can be implemented (eg Process , address pace)[1]
** Exokernels should avoid resource management except when required protection ( allocation , revocation , ownership)[1]
** application based resource management is the best way to build flexible efficient flexible systems [1]
*Expose allocation[1]
** allow LibOs to request physical resources [1]
** resource allocation should not be automatic, the LibOS should participate in every single allocation decision [1]
*Expose Names[1]
** Use physical name's when ever possible[3] (not to sure what physical names are, I think it is as simple as what the hardware is called)--[[User:Asoknack|Asoknack]] 20:27, 9 October 2010 (UTC)
** Physical names capture useful information [3]
*** safer than and less resource intensive than virtual names as no translations are needed[3]
*Expose Revocation [1]
** use visible revocation protocol [1]
** allows well behaved LibOS to preform application level resource management [1]
** Visible revocation allows the LibOS to choose what instance of the resource to release[1](Visible means that when revocation happens the exokernel tell the LibOS that resource is being revoked)
''' Policy '''
* LibOS handle resource policy decisions
* Exokernels have a policy to decided between competing LibOS (Priority , share of resources)
** it enforces this threw allocation and deallocation (every thing can achieved threw this even what block to write and such)

==== Secure Bindings ====
* Used by the exokernel to allow the LibOS to bind to resources [1]
* Allows the separation of protection and resource use [1]
* only checks authorization during bind time [1]
** Application's with complex needs for resources only authorized during bind.[1]
* access checking is done during access time and there is no need to understand complex resources needs during access[1]
** (this means that the exokernel checks once to make sure an application has authorization once approved, when the application tries to use the resource the exokernel is only concerned about policy conflict's)--[[User:Asoknack|Asoknack]] 18:20, 9 October 2010 (UTC)
** allows the kernel to protect the resources with out understanding what the resource is [1]
*three way's to implement
* Hardware Mechanisms [1]
* Software caching [1]
* Downloading application code [1]
''' Downloading Code to the Kernel '''
* used to implement secure bindings , and improve performance[1]
** eliminate the number of kernel crossings [1]
** downloaded code can be run with out the application to be scheduled [2]
==== Visible Resource Revocation ====
* Used for most resources [1]
** allows for LibOS to help with deallocation [1]
** LibOS are able to garner what resources are scare [1]
* Slower than Invisible as application involvement is required [1]
** ex of when invisible is used is Processor addressing-context identifiers [1]
==== Abort Protocol ====
* allows the exokernel to take resources away from the LibOS [1]
* used when the LibOS fails to respond to the revocation request [1]
* Exokernel must be careful not to delete as the LibOS might need to write some system critical data to the resource [1]

== Comparisons ==
====Exokernel/Microkernel====
'''Similarities'''
* Limited functionality in kernel
** functionality in kernel to handle sharing of resources and security
** avoids programming directly to hardware which creates a dependency
* Additional functionality provided in user space as processes
'''Differences'''
* Minimal abstractions provided by the kernel
** Applications given more power in exokernel

====Exokernel/VM====
'''Similarities'''
* Idea of partitioning resources between applications/OSs
* "Control" of resource given
* Isolation from other applications/OSs
'''Differences'''
* Exokernel runs applications, VM runs OS
* VM uses a hostOS and guestOSs run on top
* Virtualization on VMs, Exokernel deals with real resources
* VM hides a lot of information because it emulates. Exokernel does not.

====Microkernel/VM====
'''Differences'''
* With a virtual machine, you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System.
* This can be costly but the benefits are that it's easier and all the standard OS features are available.

== References ==
[1]<nowiki> Engler, D. R., Kaashoek, M. F., and O'Toole, J. 1995. Exokernel: an operating system architecture for application-level resource management. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 251-266. DOI= http://doi.acm.org/10.1145/224056.224076 </nowiki>

[2]<nowiki>Engler, Dawson R. "The Exokernel Operating System Architecture." Diss. Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 1998. Web. 9 Oct. 2010. <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5054&rep=rep1&type=pdf>.</nowiki>

[3]<nowiki>Kaashoek, M. F., Engler, D. R., Ganger, G. R., Briceño, H. M., Hunt, R., Mazières, D., Pinckney, T., Grimm, R., Jannotti, J., and Mackenzie, K. 1997. Application performance and flexibility on exokernel systems. In Proceedings of the Sixteenth ACM Symposium on Operating Systems Principles (Saint Malo, France, October 05 - 08, 1997). W. M. Waite, Ed. SOSP '97. ACM, New York, NY, 52-65. DOI= http://doi.acm.org/10.1145/268998.266644 </nowiki>

[4]<nowiki>Vallee, G.; Naughton, T.; Engelmann, C.; Hong Ong; Scott, S.L.; , "System-Level Virtualization for High Performance Computing," Parallel, Distributed and Network-Based Processing, 2008. PDP 2008. 16th Euromicro Conference on , vol., no., pp.636-643, 13-15 Feb. 2008
DOI= http://doi.acm.org/10.1109/PDP.2008.85 </nowiki>

[5]<nowiki>Goldberg, R. P. 1973. Architecture of virtual machines. In Proceedings of the Workshop on Virtual Computer Systems (Cambridge, Massachusetts, United States, March 26 - 27, 1973). ACM, New York, NY, 74-112. DOI= http://doi.acm.org/10.1145/800122.803950 </nowiki>

[6]<nowiki>Vallee, G., Naughton, T., and Scott, S. L. 2007. System management software for virtual environments. In Proceedings of the 4th international Conference on Computing Frontiers (Ischia, Italy, May 07 - 09, 2007). CF '07. ACM, New York, NY, 153-160. DOI= http://doi.acm.org/10.1145/1242531.1242555 </nowiki>

[7]<nowiki>Liedtke, J. 1995. On micro-kernel construction. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 237-250. DOI= http://doi.acm.org/10.1145/224056.224075 </nowiki>

== Unsorted ==
Exokernel-
Minimalistic abstractions for developers
Exokernels can be seen as a good compromise between virtual machines and microkernels in the sense that exokernels can give that low level access to developers similar to direct access through a protected layer and at the same time can contain enough hardware abstraction to allow similar benefit of hiding the hardware resources to application programs.
Exokernel – fewest hardware abstractions to developer
Microkernel - is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system
Virtual machine is a simulation of any or devices requested by an application program
Exokenel – I’ve got a sound card
Virtual Machine – I’ve got the sound card you’re looking for, perfect virtual match
Microkernel – I’ve got sound card that plays Khazikstan sound format only
MicroKernel - Very small, very predictable, good for schedualing (QNX is a microkernel - POSIX compatable, benefits of running linux software like modern browsers)

This is some ideas I've got on this question, please contribute below
-Rovic

Outlining some main features here as I see them.

I found that the exokernel was an even lower-level design than the microkernel, closer to the hardware without abstraction. They have the same architecture with the basic functionality contained in the kernel to manage everyone. As the exokernel "gives" the resource to the application it can use the resource in isolation of other applications (until forced to shared) much like VMs receive their resources, either partitioned or virtualized, and execute as if its running on its own machine. There is this similar notion of partitioning the resources among applications/OS and allowing them to take control of what they have.

I'll locate some references later on. --[[User:Slay|Slay]] 15:00, 7 October 2010 (UTC)

I'm just going to post my answer for question 1 on the individuel assignment and hope it helps. --[[User:Aellebla|Aellebla]] 15:06, 12 October 2010 (UTC)

The design of the micro kernel was to take everything they could out of the Kernel and put it into a process. For ex, networking would be put into a process instead of staying in the kernel. The micro kernel dev's tried to keep lots of things in user space for efficiency. But one major problem with this is there would be a large amount of moving from a process to the kernel to user space and back again and this is a costly, non efficient process.It was an application specific OS, there was no multiplexing. With a virtual machine you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System. This is very heavy however but the benefits are that it‟s easy and all the standard OS features are there whereas in a microkernel setup they would not all be there and this can be seen as a compromise.

Exokernels can be seen as a compromise to virtual machines and microkernels because virtual machines emulate and exokernels do not. When you emulate something you hide a lot of the actual information because you wouldn‟t be able to see the „real‟ hardware. If we look at a virtual box setup running Linux, and we go look at all the hardware, it will be displayed as fake hardware.

Maybe we can have an introduction - paragraph or so on each type - then similarities - differences - and the compromise. I am going to do some research and writing this weekend and I will put some up -- Jslonosky

btw in my page (i guess you can call it that) i have some resources i have found --[[User:Asoknack|Asoknack]] 15:50, 8 October 2010 (UTC)
- Wow, nice man. I will go ahead and write up the descriptive paragraphs on each kernel and virtual machine if no one minds. --Jslonosky

I think we should divide up the paragraphs and proofread each others instead. (Are there only 4 of us?) I don't have much time to work on this today though but I'll try to work on it tomorrow morning. - Slay

Sure guy. That sounds good. There should be 5 or 6 of us though.. . Oh well. Their loss. I will do some before or after work today. Ill start with Microkernel since there is not a large amount of info here, and so we don't overlap each other - JSlonosky

yeah i think there was more like 7 of us btw if any one has any more information feel free to add it would be nice if you add the references so that way citing is really easy on acm.org it will auto give you the citation info (where it says Display Formats click on ACM Ref and new window with the citation info auto pop's up) --[[User:Asoknack|Asoknack]] 02:28, 11 October 2010 (UTC)

I added an outline of the similarities and differences. Add any more that I missed. These are from observations so I don't have any resources. -Slay
That's probably fine. Our textbook probably outlines some of them, so I am sure we can find a few there - JSlonosky

Talked to the teacher today and for VM he said we should focus on the implementation such as Xen and VMware , he also said to talk about para virtualization --[[User:Asoknack|Asoknack]] 18:42, 12 October 2010 (UTC)

== The Essay ==

Let's actually breakdown the essay into components then write it here.

We have our intro/thesis statement

...to the extent that exokernels be seen as a compromise between virtual machines and microkernels.
-I'll work on the initial intro, should have it ready by tonight. -Slade

3 paragraphs that prove it
Explain how the key design characteristics of these three system architectures compare with each other.

and conclusion

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-12T18:43:04Z

Asoknack: /* Microkernel */

== Microkernel ==
* Moving kernel functionality into processes contained in user space, e.g. file systems, drivers
* Keep basic functionality in kernel to handle sharing of resources
* Separation allows for manageability and security, corruption in one does not necessarily cause failure in system
* Large amount of moving from a process to Kernel to user space and back again, this is a costly operation.

----

''' Microkernel '''
* try's to minimize the amount of software that is mandatory or required [7]
advantages of Microkernel
* favors a modular system structure [7]
* one failure of a program does not impact any other programs [7]
* can support more than one api or strategies since all programs are separated [7]
==== Microkernel Concepts ====
===== Address Space =====
===== Thread's IPC =====
===== Unique Identifiers =====

== Virtual Machine ==
* Partitioning or virtualizing resources among OS virtualization running on top of host OS
* Virtualized OS believe running on full machine on its own

----
System Level Virtualization

=== VMM ===
* stands for Virtual Machine Monitor, also known as the hyper-visor[4]
* responsible for virtualization of hardware(mapping physical to virtual) and the VM that run on top of the virtuallized hardware [4]
* usually a small os with no drivers , so it is coupled with a linux distro that provides device / hardware access [4]
** the os that the VMM is using for driver's is called the hostOS [6]
*the hostOS provides login and physical access to the hardware as well as management for the VMM [6]
=== VM ===
* the OS that the vm is running is called the guestOS [6]
* the guestOS only sees resources that have been allocated to the VM [6]
==== three approaches ====
*Type I virtualization [5]
** runs off the physical hardware [4]
** Isolation of the guestOs from the hardware is done threw processe level protection meachnism[6]
*** ring 0 = VMM [6]
*** ring 1 = VM [6]
*** this means all instructions from the VM must go threw the VMM [6]
** since there can be multiple VM's on a computer the scheduling is done by the VMM [6]
** on boot the VMM creates a hardware platform for the VM [6]
** load's the VM kernel into virtual memory and then boot's it like a regular computer [6]
** ex. Xen [4]
*Type II virtualization [5]
** run off the host Os [4]
** ex. VMware , QEMU [4]
* Para-virtualization [6]
** Similar to Type but use the HostOs for Device driver access [6]

== Exokernel ==
* Micro-kernel architecture with limited abstractions, ask for resource, get resource not resource abstraction
* Less functionality provided by kernel, security and handling of resource sharing
* Once application receives resource, it can use it as it wishes/in control
* Keep the basic kernel to handle allocating resources and sharing rather than developing straight to the hardware

----
* multiplex resources securely providing protection to mutual distrustful application threw the use of secure binding's[1]
* Goal of the exokernel is to give LibOS maximum freedom with out allowing them to interfere with each other. to do this the exokernel separates protection from management in doing this it provide 3 important tasks[1]
** tracking ownership of resources [1]
** ensuring protection by guarding all resource usage and binding points (not to shure what binding points are)[1]
** revoking access to the resources [1]
* LibrayOS (LibOs)
** Reduces the number of kernel crossings[1]
** Not trusted by the exokernel so can be trusted by the application , Example given is a bad parameter passed to the LibOs only the application is affected.[1] (So LibOs cant interact with kernel ???)
** Any application running on the Exokernel can change the LibrayOs freely [1]
** Application that use LibOS that implement standard interfaces (POSIX) will be portable on any system with the same interface [1]
** LibOs can be made portable if it is designed to interact with a low-level machine independent level to hide hardware details [1]

=== Exokernel Design ===
==== Design Principles ====
*Securely Expose Hardware [1]
** an Exokernel tries to create low level primitives that the hardware resources can be accessed from, this also includes interrupts,exceptions [1]
** the exokernel also export privileged instructions to the LibOS so that traditional OS abstractions can be implemented (eg Process , address pace)[1]
** Exokernels should avoid resource management except when required protection ( allocation , revocation , ownership)[1]
** application based resource management is the best way to build flexible efficient flexible systems [1]
*Expose allocation[1]
** allow LibOs to request physical resources [1]
** resource allocation should not be automatic, the LibOS should participate in every single allocation decision [1]
*Expose Names[1]
** Use physical name's when ever possible[3] (not to sure what physical names are, I think it is as simple as what the hardware is called)--[[User:Asoknack|Asoknack]] 20:27, 9 October 2010 (UTC)
** Physical names capture useful information [3]
*** safer than and less resource intensive than virtual names as no translations are needed[3]
*Expose Revocation [1]
** use visible revocation protocol [1]
** allows well behaved LibOS to preform application level resource management [1]
** Visible revocation allows the LibOS to choose what instance of the resource to release[1](Visible means that when revocation happens the exokernel tell the LibOS that resource is being revoked)
''' Policy '''
* LibOS handle resource policy decisions
* Exokernels have a policy to decided between competing LibOS (Priority , share of resources)
** it enforces this threw allocation and deallocation (every thing can achieved threw this even what block to write and such)

==== Secure Bindings ====
* Used by the exokernel to allow the LibOS to bind to resources [1]
* Allows the separation of protection and resource use [1]
* only checks authorization during bind time [1]
** Application's with complex needs for resources only authorized during bind.[1]
* access checking is done during access time and there is no need to understand complex resources needs during access[1]
** (this means that the exokernel checks once to make sure an application has authorization once approved, when the application tries to use the resource the exokernel is only concerned about policy conflict's)--[[User:Asoknack|Asoknack]] 18:20, 9 October 2010 (UTC)
** allows the kernel to protect the resources with out understanding what the resource is [1]
*three way's to implement
* Hardware Mechanisms [1]
* Software caching [1]
* Downloading application code [1]
''' Downloading Code to the Kernel '''
* used to implement secure bindings , and improve performance[1]
** eliminate the number of kernel crossings [1]
** downloaded code can be run with out the application to be scheduled [2]
==== Visible Resource Revocation ====
* Used for most resources [1]
** allows for LibOS to help with deallocation [1]
** LibOS are able to garner what resources are scare [1]
* Slower than Invisible as application involvement is required [1]
** ex of when invisible is used is Processor addressing-context identifiers [1]
==== Abort Protocol ====
* allows the exokernel to take resources away from the LibOS [1]
* used when the LibOS fails to respond to the revocation request [1]
* Exokernel must be careful not to delete as the LibOS might need to write some system critical data to the resource [1]

== Comparisons ==
====Exokernel/Microkernel====
'''Similarities'''
* Limited functionality in kernel
** functionality in kernel to handle sharing of resources and security
** avoids programming directly to hardware which creates a dependency
* Additional functionality provided in user space as processes
'''Differences'''
* Minimal abstractions provided by the kernel
** Applications given more power in exokernel

====Exokernel/VM====
'''Similarities'''
* Idea of partitioning resources between applications/OSs
* "Control" of resource given
* Isolation from other applications/OSs
'''Differences'''
* Exokernel runs applications, VM runs OS
* VM uses a hostOS and guestOSs run on top
* Virtualization on VMs, Exokernel deals with real resources
* VM hides a lot of information because it emulates. Exokernel does not.

====Microkernel/VM====
'''Differences'''
* With a virtual machine, you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System.
* This can be costly but the benefits are that it's easier and all the standard OS features are available.

== References ==
[1]<nowiki> Engler, D. R., Kaashoek, M. F., and O'Toole, J. 1995. Exokernel: an operating system architecture for application-level resource management. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 251-266. DOI= http://doi.acm.org/10.1145/224056.224076 </nowiki>

[2]<nowiki>Engler, Dawson R. "The Exokernel Operating System Architecture." Diss. Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 1998. Web. 9 Oct. 2010. <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5054&rep=rep1&type=pdf>.</nowiki>

[3]<nowiki>Kaashoek, M. F., Engler, D. R., Ganger, G. R., Briceño, H. M., Hunt, R., Mazières, D., Pinckney, T., Grimm, R., Jannotti, J., and Mackenzie, K. 1997. Application performance and flexibility on exokernel systems. In Proceedings of the Sixteenth ACM Symposium on Operating Systems Principles (Saint Malo, France, October 05 - 08, 1997). W. M. Waite, Ed. SOSP '97. ACM, New York, NY, 52-65. DOI= http://doi.acm.org/10.1145/268998.266644 </nowiki>

[4]<nowiki>Vallee, G.; Naughton, T.; Engelmann, C.; Hong Ong; Scott, S.L.; , "System-Level Virtualization for High Performance Computing," Parallel, Distributed and Network-Based Processing, 2008. PDP 2008. 16th Euromicro Conference on , vol., no., pp.636-643, 13-15 Feb. 2008
DOI= http://doi.acm.org/10.1109/PDP.2008.85 </nowiki>

[5]<nowiki>Goldberg, R. P. 1973. Architecture of virtual machines. In Proceedings of the Workshop on Virtual Computer Systems (Cambridge, Massachusetts, United States, March 26 - 27, 1973). ACM, New York, NY, 74-112. DOI= http://doi.acm.org/10.1145/800122.803950 </nowiki>

[6]<nowiki>Vallee, G., Naughton, T., and Scott, S. L. 2007. System management software for virtual environments. In Proceedings of the 4th international Conference on Computing Frontiers (Ischia, Italy, May 07 - 09, 2007). CF '07. ACM, New York, NY, 153-160. DOI= http://doi.acm.org/10.1145/1242531.1242555 </nowiki>

[7]<nowiki>Liedtke, J. 1995. On micro-kernel construction. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, United States, December 03 - 06, 1995). M. B. Jones, Ed. SOSP '95. ACM, New York, NY, 237-250. DOI= http://doi.acm.org/10.1145/224056.224075 </nowiki>

== Unsorted ==
Exokernel-
Minimalistic abstractions for developers
Exokernels can be seen as a good compromise between virtual machines and microkernels in the sense that exokernels can give that low level access to developers similar to direct access through a protected layer and at the same time can contain enough hardware abstraction to allow similar benefit of hiding the hardware resources to application programs.
Exokernel – fewest hardware abstractions to developer
Microkernel - is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system
Virtual machine is a simulation of any or devices requested by an application program
Exokenel – I’ve got a sound card
Virtual Machine – I’ve got the sound card you’re looking for, perfect virtual match
Microkernel – I’ve got sound card that plays Khazikstan sound format only
MicroKernel - Very small, very predictable, good for schedualing (QNX is a microkernel - POSIX compatable, benefits of running linux software like modern browsers)

This is some ideas I've got on this question, please contribute below
-Rovic

Outlining some main features here as I see them.

I found that the exokernel was an even lower-level design than the microkernel, closer to the hardware without abstraction. They have the same architecture with the basic functionality contained in the kernel to manage everyone. As the exokernel "gives" the resource to the application it can use the resource in isolation of other applications (until forced to shared) much like VMs receive their resources, either partitioned or virtualized, and execute as if its running on its own machine. There is this similar notion of partitioning the resources among applications/OS and allowing them to take control of what they have.

I'll locate some references later on. --[[User:Slay|Slay]] 15:00, 7 October 2010 (UTC)

I'm just going to post my answer for question 1 on the individuel assignment and hope it helps. --[[User:Aellebla|Aellebla]] 15:06, 12 October 2010 (UTC)

The design of the micro kernel was to take everything they could out of the Kernel and put it into a process. For ex, networking would be put into a process instead of staying in the kernel. The micro kernel dev's tried to keep lots of things in user space for efficiency. But one major problem with this is there would be a large amount of moving from a process to the kernel to user space and back again and this is a costly, non efficient process.It was an application specific OS, there was no multiplexing. With a virtual machine you are not virtualizing apps like with a microkernel but virtualizing an entire Operating System. This is very heavy however but the benefits are that it‟s easy and all the standard OS features are there whereas in a microkernel setup they would not all be there and this can be seen as a compromise.

Exokernels can be seen as a compromise to virtual machines and microkernels because virtual machines emulate and exokernels do not. When you emulate something you hide a lot of the actual information because you wouldn‟t be able to see the „real‟ hardware. If we look at a virtual box setup running Linux, and we go look at all the hardware, it will be displayed as fake hardware.

Maybe we can have an introduction - paragraph or so on each type - then similarities - differences - and the compromise. I am going to do some research and writing this weekend and I will put some up -- Jslonosky

btw in my page (i guess you can call it that) i have some resources i have found --[[User:Asoknack|Asoknack]] 15:50, 8 October 2010 (UTC)
- Wow, nice man. I will go ahead and write up the descriptive paragraphs on each kernel and virtual machine if no one minds. --Jslonosky

I think we should divide up the paragraphs and proofread each others instead. (Are there only 4 of us?) I don't have much time to work on this today though but I'll try to work on it tomorrow morning. - Slay

Sure guy. That sounds good. There should be 5 or 6 of us though.. . Oh well. Their loss. I will do some before or after work today. Ill start with Microkernel since there is not a large amount of info here, and so we don't overlap each other - JSlonosky

yeah i think there was more like 7 of us btw if any one has any more information feel free to add it would be nice if you add the references so that way citing is really easy on acm.org it will auto give you the citation info (where it says Display Formats click on ACM Ref and new window with the citation info auto pop's up) --[[User:Asoknack|Asoknack]] 02:28, 11 October 2010 (UTC)

I added an outline of the similarities and differences. Add any more that I missed. These are from observations so I don't have any resources. -Slay
That's probably fine. Our textbook probably outlines some of them, so I am sure we can find a few there - JSlonosky

Talked to the teacher today and for VM he said we should focus on the implementation such as Xen and VMware , he also said to talk about para virtualization --[[User:Asoknack|Asoknack]] 18:42, 12 October 2010 (UTC)

== The Essay ==

Let's actually breakdown the essay into components then write it here.

We have our intro/thesis statement

...to the extent that exokernels be seen as a compromise between virtual machines and microkernels.
-I'll work on the initial intro, should have it ready by tonight. -Slade

3 paragraphs that prove it
Explain how the key design characteristics of these three system architectures compare with each other.

and conclusion

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-12T18:42:10Z

Asoknack: /* Unsorted */

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-12T18:40:56Z

Asoknack: /* Microkernel */

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-12T18:30:33Z

Asoknack: /* Virtual Machine */

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-11T02:30:17Z

Asoknack: /* Unsorted */

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-11T02:28:44Z

Asoknack: /* Unsorted */

Template:Reflist

2010-10-09T22:51:49Z

Asoknack: Created page with '<div class="references-small {{#if: {{{colwidth|}}} | references-column-width | {{#iferror: {{#ifexpr: {{{1|1}}}>1 | references-column-count references-column-count-{{{1}}} }} }}…'

<div class="references-small {{#if: {{{colwidth|}}} | references-column-width | {{#iferror: {{#ifexpr: {{{1|1}}}>1 | references-column-count references-column-count-{{{1}}} }} }} }}" {{#if: {{{colwidth|}}}| style="-moz-column-width:{{{colwidth}}}; column-width:{{{colwidth}}};" | {{#if: {{{1|}}}| style="-moz-column-count:{{{1}}}; column-count:{{{1}}};" }} }}>
{{#tag:references||group={{{group|}}}}}</div><noinclude>[[Category:Citation templates|{{PAGENAME}}]]</noinclude>

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-09T22:30:45Z

Asoknack: Spell check

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-09T22:17:29Z

Asoknack: /* References */

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-09T21:35:36Z

Asoknack: /* Virtual Machine */

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-09T21:28:03Z

Asoknack: /* Virtual Machine */

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-09T21:07:42Z

Asoknack: /* References */

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-09T21:06:38Z

Asoknack: /* Virtual Machine */

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-09T20:56:53Z

Asoknack: /* References */

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-09T20:56:18Z

Asoknack: /* Virtual Machine */

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-09T20:38:13Z

Asoknack: /* Exokernel */

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-09T20:36:29Z

Asoknack: /* References */

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-09T20:27:39Z

Asoknack: /* Exokernel */

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-09T20:18:03Z

Asoknack: /* References */

User:Asoknack

2010-10-09T20:09:51Z

Asoknack:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.120.4319&rep=rep1&type=pdf 
http://portal.acm.org/citation.cfm?id=219284 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5054&rep=rep1&type=pdf 
http://portal.acm.org/citation.cfm?id=224076 
http://portal.acm.org/citation.cfm?id=268998.266644&coll=GUIDE&dl=GUIDE&CFID=104701711&CFTOKEN=65527198

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-09T20:08:21Z

Asoknack: /* Exokernel Design */

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-09T19:36:26Z

Asoknack: /* Design Principles */

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-09T19:35:17Z

Asoknack:

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-09T19:34:47Z

Asoknack:

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-09T19:26:43Z

Asoknack: /* Exokernel */

Talk:COMP 3000 Essay 1 2010 Question 1

2010-10-09T18:29:22Z

Asoknack: /* Exokernel */