M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrman, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser. Overview of the CHORUS distributed operating system. Proceedings of the USENIX Workshop on Micro-Kernels and Other Kernel Architectures, pp. 39--69. USENIX Assoc., Berkeley, CA, 1992.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....micro kernels, because they (micro kernels) enforce modular design, appropriated for highly dependable systems [8, 9] and because most of current distributed operating systems are based on the microkernel concept, with classical operating system services provided by user level processes. Chorus [10], Amoeba [11] and Mach [12] are good examples of it. Even when traditional kernels are used, numerous distributed services are nevertheless implemented by user level code. In this paper, this new set of kernel services which we have called Incremental Operations after incremental ....

M. Rozier, V. Abrossimov, et al., "Overview of the Chorus Distributed Operating System", USENIX Micro-kernels and Other Kernel Architectures Workshop Proc., April 1992, pp. 39-69.

....The lowest level software system in the Sting architecture is the physical machine layer. This layer coordinates the physical processors and creates and manages virtual machines.The physical machine abstraction is equivalent to the micro kernel in other modern operating systems such as Chorus [11], Mach [12] or Psyche [9] The physical machine kernel is an abstraction of the physical hardware. The physical hardware is composed of some number of processors, physical memory, and devices connected in a physical topology. The physical machine controls and coordinates the interaction of the ....

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrman, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser. Overview of the chorus distributed operating system. In Usenix Workshop: Micro-Kernels and Other Kernel Architectures, pages 39--69. Association for Computing Machinery SIGOPS, April 1992.

....present concluding remarks and directions for future work. 2 Related Work Many research operating systems have been developed that implemented process migration mechanisms, with a focus on using migration for load balancing. These sys tems include Accent [31] Amoeba [25] Charlotte [6] Chorus [33], MOSIX [7] Sprite [12] and V [11] These operating systems provided a single system image across a cluster of machines and providing migration throughout the cluster through careful kernel design to provide a global namespace and location transparent execution. Process state such as IPC, open ....

M. Rozier, V. Abrossimov, F. Armand, M. Gien, M. Guillemont, F. Hermann, and C. Kaiser, Chorus (Overview of the Chorus Distributed Operating System), Proceedings of the USENIX Workshop on Micro-Kernels and other Kernel Architectures, Seattle, WA, April 1992.

....download a new component into the kernel. To support these features, it should be possible to resolve the bindings between components at run time. Building flexible systems from components has been an active area of operating system research. Previous work includes micro kernel architectures [2, 14, 25], where each component corresponds to a domain boundary (i.e. server) extensible systems such as SPIN [3] that support dynamic loading of components written in a type safe language, and more recently the OSKit [7] or eCos [5] which allow the re use of existing system components. One problem with ....

V. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrmann, C. Kaiser, S. Langlois, P. L eonard, and W. Neuhauser. Overview of the Chorus distributed operating system. In Proceedings of the USENIX Workshop on Micro-Kernels and Other Kernel Architectures, pages 39--70, April 1992.

....interface to the hardware devices within the enhancement unit, the processor needs to support a distributed systems platform similar to that developed for the MNI system. To overcome some of the limitations with the original interface we are developing a new version around the Chorus micro kernel [Rozier,90] which must therefore, also be supported by the enhancement processor. Video. If this system is to be used in real multimedia applications, full frame rate video must be supported. Many multimedia applications will require multiple streams of video to be output simultaneously within windows on ....

Rozier, M., Abrossimov. V., Arnould, F., Boule, I., Gien, M., Guillemont, M., Herrmann, F., Kaiser C., Langlois, S., Leonard, P., Neuhauser, W. "Overview of the CHORUS Distributed Operating Systems", Chorus Systems, CS/TR-90-25, April 15, 1990.

....Hence, it s difficult to achieve service differentiation and allocation guarantee using a best effort scheduler. In order to meet the timeliness requirements presented by multimedia applications, much work in recent years has been focusing on applying real time techniques to multimedia systems [50, 36, 70, 44, 79, 22, 10, 39, 80, 73, 72, 56]. However, most of real time schedulers require the global knowledge of the workload and the precise CPU bandwidth requirement of each application. As described in Section 1.2, such information is often hard to obtain in a dynamic environment featuring multimedia applications. Furthermore, ....

....of the approaches have been built upon general purpose operating systems used in most enterprise servers and personal computers (e.g. Solaris [6] xBSD[52] Linux [3] Windows NT [71] etc. others have been built upon experimental prototype real time systems (e.g. Real time Mach [79] Chorus [22], Spring [74] DASH [10] Eclipse [15] etc. Most of these approaches addressed one or two of three levels of abstractions described in section 1.2. In the rest of the section, we summarize these approaches in the context of their respective level of abstraction, and discuss how each of them ....

[Article contains additional citation context not shown here]

M. Rozier et al. Overview of the CHORUS Distributed Operating System. In Proceedings of the USENIX Workshop on Micro-kernels and Other Kernel Architectures, pages 39--69, April 1992.

....in other ways. 2.4.4 Soft real time system support Several multimedia systems have used scheduling algorithms like earliest deadline first to make the system more sensitive to timing without necessarily guaranteeing that timing 24 constraints will be met. For example, a system based on Chorus [103] proposed using deadline scheduling with no admission control [21] Other algorithms such as lottery scheduling [133] attempt to support multimedia applications using proportional sharing of resources without real time delay guarantees. A deterministic version of the approach called stride ....

....demonstrates how such an interface can be used by an application. In contrast, the reserve system provides flexibility in reservation binding for a more integrated view of resource usage reservation, measurement, and enforcement. Coulson et al. 21] present a system design based on Chorus [103]. This system uses earliest deadline scheduling, but they do not provide any admission control and usage enforcement. QOS commitments can be revoked, and overload is permitted; commitments are degraded as a response to overload. The work focuses primarily on fast context switching and reducing ....

M. Rozier et al. Overview of the CHORUS Distributed Operating System. In Proceedings of the USENIX Workshop on Micro-kernels and Other Kernel Architectures, pages 39--69, April 1992.

....domain in mind. Unfortunately, this domain is typically the only domain for which the custom system is suitable for; if a new domain is to be targeted then a new custom operating system must be constructed. Several custom operating systems have achieved commercial success including Chorus [Rozier,92] in the field of telecommunications, QNX [Hildebrand,92] in the field of real time and embedded systems and BeOS [Be,00] in the field of multimedia applications. In addition, a myriad of research based custom operating systems (including Serpent [Waddington,99] Roadrunner [Miller,96] Pegasus ....

.... (when services compete for the same resources) All these issues must be addressed for the system to be classed as extensible rather than just a system that supports ad 10 hoc service integration, as in the case of Linux [Beck,96] and SunOS [Sun,91] with loadable kernel modules) and Chorus [Rozier,92] with supervisor actors) Network Protocols Memory Management Inter Process Communication Mechanisms HARDWARE System Programming Interface Extensible Kernel Kernel Address Space Concurrency Management Available Service Slot System Executive Application Application User Address ....

[Article contains additional citation context not shown here]

Rozier, M., Abrossimov, V., Armand, F., Boule, I., Gien, M., Guillemont, M., Herrmann, F., Kaiser, C., Langlois, S., Leonard, P., Neuhauser, W., "Overview of the Chorus Distributed Operating System". Proceedings of the USENIX Workshop on Micro-kernels and other Kernel Architectures, pp 39-69, Seattle WA, U.S.A., April 1992.

.... system achieves su#cient fail safety, but the performance is sacrificed because the overheads of inter process communication (IPC) and context switches are large [3, 7] The performance of this cross domain communication has been improved 6 in recent years [22] The Chorus operating system [38, 37] allows users to download the extension modules created as the user level servers into the kernel without recompiling them. This approach achieves both su#cient fail safety at the user level and good performance at the kernel level. However, since the communication between the extension modules ....

Rozier, M., V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrman, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser, "Overview of the Chorus Distributed Operating System," in Proceedings of the USENIX Symposium on Microkernels and Other Kernel Architectures, pp. 39--69, Apr. 1992.

....cluster processing[8, 32] In contrast, Alpine is focused on normal applications that use normal networking APIs. 2. Per application specialization. Many have shown that special kernel modifications or downloadable kernel code make application specialization of the networking stack possible [7, 9, 14, 15, 21, 24, 27, 29, 33]. Alpine supports specialization, but this is not its focus. Since our design constraints include requiring no kernel or application modifications, Alpine cannot achieve the high performance of many of these systems. 3. Simplified development. Work has also been done to make kernel development ....

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrmann, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser. Overview of the chorus distributed operating system. In Proceedings USENIX Workshop on Micro-kernels and Other Kernel Architectures, pages 39--69, 1992.

....is possible to analyze the content of each request to determine if it is a high load request, but this requires aprioriknowledge of the requests behavior, which may not be feasible in many distributed computing systems. OS based load balancing: Some distributed operating systems, such as Chorus [17], can distribute processes transparently across remote OS endsystem nodes. Tools, such as GNU Queue [18] run a service that allows a user to run remote processes as if they were run on the local machine, i.e. essentially transparently. Load balancing performed at this level has the advantage ....

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrmann, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser, "Overview of the CHORUS Distributed Operating Systems," Tech. Rep. CS-TR-90-25, Chorus Systems, 1990. 11

....are based solely on the destination of the request. The content of the request is often ignored. This form of load balancing also makes it difficult to select the load metric to be used when making balancing decisions. OS based load balancing: Load balancing at the operating system level [22, 23, 24] has the advantage of performing the balancing at multiple levels. That balancing is essentially transparent to a distributed application. However, it suffers from many of the same problems that network based load balancing suffers from, such as inflexible load metric selection and not being able ....

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrmann, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser, "Overview of the CHORUS Distributed Operating Systems," Tech. Rep. CS-TR-90-25, Chorus Systems, 1990.

....non critical data, and deallocation of resources [4, page 131] Smith and Williams [17] give an example of real time system performance engineering of a design which includes a second phase. Many existing distributed operating systems support second phase execution, including Ameoba [18] Chorus [16], V [2] and Sun RPC [4] Second phase service is also directly supported in the programming language Ada [1] The two phases of service are illustrated in Figure 1. The time interval from the instant of the receive at the server to the time of the reply is described as phase one; the server ....

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M Guillemont, F. Herrmann, C. Kaiser, S. Langlois, P. L'eonard, and W. Neuhauser. Overview of the chorus distributed operating systems. Technical Report CS/TR-90-25, Chorus Syst`emes, February 1991.

....system security policy. As has been known for quite some time [24, 15, 11] an effective security policy must be able to control all accesses to all objects exported by components (and protect itself from tampering [1] Unfortunately, early component based systems, such as Mach [18] Chorus [19], and Spring [16] only control access to component communication, not objects. In addition, despite the limited security flexibility provided by these systems, they still were shown to display less than effective performance [12] Therefore, building a high performance system that still provides ....

....should be able to handle these mechanisms. The traditional problem in enforcing system security policies on server objects is that the system TCB knows the security policy, but the server knows the object space. Traditional micro kernel security models, such as those in Mach [18] Chorus [19], and Spring [16] control communication between protection domains, but depend on the servers to enforce the security policy on objects and control delegation. Thus, the enforcement of system security policy on object accesses is primarily the job of the servers. DTOS [15] addresses this problem ....

M. Rozier and et al. Overview of the Chorus distributed operating system. In USENIX Symposium on Micro-kernels and Other Kernel Architectures, pages 39--69, 1992.

....and web services (notably from Sun, Tandem, IBM and Microsoft) The promise of distributed computing for generalpurpose computations was a major thrust in the development of Distributed Operating Systems in the mid 1980s. Operating systems such as Amoeba [27] Mach [21] Clouds [7] Chorus [22], and so on failed to bring the power of distributed general purpose computing to the desktop. In retrospect, the shortcoming of these systems resulted from the application development barrier. The application development barrier is the void of applications for a new platform. If we design a new ....

....in the past without any major impact to distributed computing. Process migration has typically been used for load balancing in parallel processing systems and includes systems such as MPVM [5] and DynamicPVM [8] and Chime [27] Operating systems that support process migration include Chorus [22], MOSIX [3] Amoeba [27] and Sprite [11] However in these systems, the applications have restrictions, or have to be written for the particular OS, or have to be recompiled or re linked. Past attempts at process migration have been limited to processes without any I O connections or GUI ....

M. Rozier, V. Abrossimov, F. Armand, M. Gien, M. Guillemont, F. Hermann and C. Kaiser, Chorus (Overview of the Chorus Distributed Operating System), Proceedings of the USENIX Workshop on Micro-Kernels and Other Kernel Architectures, 1992.

....they do not protect the address space from eavesdropping on the network, and there is no fine grained access control to the shared memory areas. These issues have all been addressed by our system. There have been many distributed programming systems [4, 6, 18] and distributed operating systems [10, 26, 27, 28] constructed in recent years. While the goal of these systems is similar to our own, they differ in many important aspects. None of these systems present a uniform address space, but instead provide an object based model with remote operations. Each object resides in its own private address space. ....

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Glen, M. Guillemont, F. Herrman, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser. Overview of the CHORUS distributed operating system. Technical Report CS/TR-9025, Chorus systemes, April 1990.

....are dynamically created for an object as required. One disadvantage of the active object model is the deadlock. Deadlock can occur if an object does not have enough server processes to perform the requested services. In dynamic active model deadlock is less a problem. Amoeba [3] 15] CHORUS [18], Eden [3] are DOBPS which use a static number of processes in the active object model. Argus [3] uses a dynamic number of processes, and Clouds [3] and Emerald use a passive object model. 4.1.2 Object Management In distributed, object based programming systems an important function is to manage ....

Rozier, M., Abrossimov, V.,...: 'Overview of the CHORUS Distributed Operating Systems'. Technical Report: CS/TR-90-25, April 1990.

....based on the nano threads library to identify the major drawbacks and bottlenecks of the current implementation. The porting to the SGI R10000 architecture has to be completed with the port of the CPU manager and we also plan to port the execution environment on top of the Chorus microkernel [Rozi92]. 6. ....

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrman, C. Kaiser, S. Langlois, P. Lonard and W. Neuhauser, "Overview of the Chorus Distributed Operating System", Proceedings of the USENIX Workshop on Microkernels and Other Kernel Architectures, abril 1992.

....have been realized for the car driving application: ffl A mono user modular version in which synchronization and control are specified in the synchronous reactive language Signal. ffl Two multi processes versions by using PVM (Parallel Virtual Machine) 13] and Chorus (micro kernel technology) [27]. A first version of the simulation platform is currently in developpment. PVM is used to define the real time kernel which is in charge of communication and synchronization between different processes, while Signal is used to assume internal management of each process. 3.3 Simulation of an ....

M. Rozier, V. Abrassimov, F. Armand, M. Boule, M. Gien, M. Guillemont, F. Herrman, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser. Overview of the chorus distributed operating system. In Proceedings of Usenix Symposium on micro-kernels and other kernels architectures, pages 39--69, Seattle, Apr. 1992.

....Limited Code Re Use The software architecture of a system also plays a key role in code re use. Structuring a software system in terms of components is now a well recognized strategy to achieve code reuse. Notably, in the OS field, this structuring technique has lead to micro kernel architectures [2, 13, 18]. In a micro kernel architecture, each component (or server) corresponds to a domain boundary. However, communication across a domain introduces overhead. Because the software components are directly mapped into protected entities, their granularity impacts system performance. The OS architect ....

....Specifically, if the building blocks have not been clearly staged, policies and mechanisms may be intertwined. As a result, it becomes difficult to extend either mechanisms or policies. Finally, existing approaches to extending OSes enable new components to be added via modules or servers [3, 18]. However, other than memory protection, they do not offer any guarantees regarding the behavior of the added components. This limitation can have disastrous consequences considering the widespread nature of appliances. 2 A New Approach Based on Domain Specific Languages The common thread of our ....

V. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrmann, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser. Overview of the Chorus distributed operating system. In USENIX - Workshop Proceedings - Micro-kernels and Other Kernel Architectures, pages 39--70, Seattle, WA, USA, April 1992.

....server. This leads to some performance penalty, as context switching between address spaces is more expensive than trapping into the kernel. But with rapid strides being made in hardware speeds, the extra modularity is worth a little fall in performance. Mach [ABB 86] QNX [Hil92] Chorus [Roz92] and Amoeba [vR92] are some examples for microrkernels. 1 To use the IPC facility of the kernel, one would still have to make a system call. This call would, however, be different than the one made in the case of a monolithic kernel. 2 1.2 Unix as an Application Program It is both possible ....

Marc Rozier. Chorus (overview of the chorus distributed operating system) . In USENIX Workshop on Micro-Kernels and Other Kernel Architectures, pages 39--70, Seattle, WA, April 27-28 1992. USENIX.

....community [Profeta et al. 1996, IEE 1997] Today, software executives often rely on the microkernel technology [Liedtke 1995] for flexibility reasons. Nevertheless, defining appropriate services to build a fault tolerant system on top of COTS microkernels (Chorus, Mach, Amoeba [Rashid et al. 1989, Rozier et al. 1991, Tanenbaum et al. 1991] requires a clear understanding of their faulty behavior. The main steps are the following: analysis of the microkernel in the presence of faults; definition of complementary error detection mechanisms; definition of fault tolerance services accounting for faulty ....

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrman, C. Kaiser, S. Langlois, P. Leonard and W. Neuhauser, Overview of the CHORUS Distributed Operating Systems, Chorus systemes, Technical Report, NCS/TR90 -25.1, 1991.

....controller interface. A detailed description of policy managers and virtual processors is given in [17, 26] 7 Physical Processors Sting is intended to serve as an operating system for modern programming languages. Like other contemporary operating systems (e.g. Mach[7, 29] Chorus[27], or Psyche[23] Sting s lowest level abstraction is a micro kernel called the Abstract Physical Machine (APM) The APM plays three important roles in the Sting software architecture: 1. It provides a secure and efficient foundation for supporting multiple virtual machines. 2. It isolates all ....

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrman, C. Kaiser, S. Langlois, P. Leonard, and W. Newhauser. Overview of the Chorus Distributed Operating System. In Workshop Proceedings Micro-Kenels and other Kernel Architectures, pages 39--69, April 1992.

....will probably best await the provision of means for automatically installing applications onto a suitable object oriented distributed runtime layer. We are at present just starting to investigate the suitability for this purpose of COOL [14] which runs on the Chorus micro kernel operating system [15], in the hope that this will provide us with a good basis for using FRS in connection with C . Other topics on which more work is needed include naming facilities for reference management, algorithms to compute references, and access control mechanisms for fine grain object invocation. By such ....

M. Rozier et al., "Overview of the Chorus Distributed Operating System", Chorus Systmes Technical Report, CS-TR-90-25, 1990, 45 pages.

....to be moved out of monolithic kernels and into server processes, usually for reasons of modularity and maintainability (figure 2.3c) 4 Operating systems of this kind are generally referred to as microkernel based. Well known examples include Amoeba [Tanenbaum81] Mach [Accetta86] Chorus [Rozier90], Plan9 [Pike90] and Spring [Hamilton93] The operating system kernel usually provides little more than support for kernel threads and an Inter Process Communication (IPC) mechanism such as the message passing system of Mach. Microkernel based operating systems necessarily incur performance ....

....memory communication, although several simple protocols have been implemented which require nothing more than the event channel itself, e.g the TAP protocol described in [Black94] used for start of day communication with the binder. Unlike message passing systems such as Mach [Accetta86] or Chorus [Rozier90], the kernel is not involved in the transfer of bulk data between two domains. Nemesis also separates the act of sending an event and that of losing the processor. Domains may exploit this feature to send a number of events before being preempted or voluntarily relinquishing the CPU. For bulk ....

[Article contains additional citation context not shown here]

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrmann, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser. Overview of the CHORUS Distributed Operating Systems. Technical Report Technical Report CS-TR-90-25, Chorus Systemes, 1990. (pp 19, 29)

....granularity. Micro kernels take the server approach and apply it to reorganize the entire operating system. A modest number of basic abstractions are implemented in a small ( micro ) kernel. The bulk of the operating system is moved into separate servers. Examples include Mach [1] and Chorus [45]. Exokernel [13] and Cache Kernel [9] attempt to push this organization as far as possible. In a micro kernel, the file system is usually implemented by one or more servers. In the process of reorganization, many micro kernels and their file systems have also acquired an objectoriented flavor. An ....

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrmann, C. Kaiser, S. Langlois, P. L'eonard, and W. Neuhauser. Overview of the CHORUS Distributed Operating Systems. Technical Report CS/TR-90-25, Chorus syst`emes, Apr. 1990.

....can be efficiently implemented using suitably improved memory mapped file facilities [25] Such facilities allow files stored on mass storage to be directly mapped into virtual memory. Rudimentary support for memory mapped files already exist in most modern operating systems like Mach [23] Chorus [24] and SunOS [25] 2 Double Paging Systems A key feature of a double paging system is the employment of two replacement policies to manage the buffer pool and physical memory. The database and buffer pool consist of uniformly and equally sized frames or pages, and demand driven page replacement is ....

Rozier, M. et al. Overview of the Chorus Distributed Operating System. Proc. of the USENIX Association Micro-kernels and Other Kernel Architectures Workshop, Seattle, Washington, April 1992, pp. 39-69.

.... Different experimentations have been realized: ffl A mono user modular version in which synchronization and control are specified in the synchronous reactive language SIGNAL[7] ffl Two multi processes version by using PVM (Parallel Virtual Machine) 13] and Chorus (micro kernel technology) [25]. An object oriented distributed version of the simulation platform is currently in developpment. PVM is used to define the real time kernel which is in charge of communication and synchronization between different processes, while SIGNAL is used to assume internal management of each process. PVM ....

M. Rozier, V. Abrassimov, F. Armand, M. Boule, M. Gien, M. Guillemont, F. Herrman, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser. -- Overview of the chorus distributed operating system. -- In Usenix Symposium on micro-kernels and other kernels architectures, pages 39--69, Seattle, April 1992.

....tried to use LOTOS to develop a specification of CHORUS. CHORUS is a distributed OS (or DOS) kernel, whose development started at INRIA, a French public research institute, in 1980 [6] 2] In 1986, the CHORUS Systmes company was created with the aim of turning CHORUS into an industrial product [14]. The specification presented hereafter focuses on the third version of CHORUS, and was a contribution to the ESPRIT Project 1535 Aphrodite [13] 20] The specification discussed in the present paper was preceeded by a specification of the previous version of CHORUS, CHORUS V2 [10] That first ....

Rozier M. et al "Overview of the CHORUS distributed operating system" CHORUS Technical Report TR-88-7.8, February 89, 50#p.

....(2) an application typically internalizes several operating system handles (such as socket identifiers and IP addresses) which stop being relevant upon migration. Existing approaches deal with the above problems either by relying on extensive modifications to OS structures to support migration [6, 12, 13, 10], or by requiring the use of a new application programming interface (API) 2, 4, 3, 7] whose implementation isolates the application from the consequences of migration. Neither of these choices is ideal because they cannot be applied to existing OSes and applications. Moreover, most such ....

....multiprocessor system. 2.1 Related Work Previous approaches for maintaining network connectivity fall into two broad categories: modifications to the OS network protocol stack, and introduction of a new API for accessing underlying resources. Modifying the OS network layer. Several researchers [13, 12, 6] have successfully demonstrated transparent network connectivity by across process migrations by incorporating changes to kernel data structures and protocols. For instance [13, 12] the implementation of network migration on top of the Chorus operating system modifies the network manager so that ....

[Article contains additional citation context not shown here]

Rozier, M., Abrossimov, V., Gien, M., Guillemont, M., Hermann, F., and Kaiser, C. Chorus (Overview of the Chorus distributed operating system). In Proc. of USENIX Workshop on Micro-Kernels and Other Kernel Architectures, pages 39--70, 1992. 11

.... applications of specialization classes, we are continuing the effort initiated by Cowan et al. in the area of adaptive operating system components [16] We would like to use specialization classes to specify a number of systems optimizations that have been described in the litterature (e.g. [22, 7, 35, 20]) In particular, we are redesigning a part of the Chorus IPC subsystem, to exploit opportunities for run time optimization that have not been addressed so far because of a lack of appropriate methodologies and tools. ....

V. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrmann, C. Kaiser, S. Langlois, P. L'eonard, and W. Neuhauser. Overview of the Chorus distributed operating system. In USENIX - Workshop Proceedings - Micro-kernels and Other Kernel Architectures, pages 39--70, Seattle, WA, USA, Apr. 1992.

....system is a difficult business and it is still normal for a buggy piece of loadable operating system code to bring down the whole system. 2.1. 3 Microkernel based Systems The desire for extensibility and modularity led to the development of microkernels, for example Mach [Accetta86] and Chorus [Rozier90]. Such systems move functionality into separate protection domains and processes, which communicate with each other and application processes via a small kernel, often using message passing (figure 2.2) The protection boundaries between the various components can make the operating system as a ....

....at high loads but retains the benefits of interrupt driven operation when system load is low. 69 In terms of inter process communication, few systems have separated signalling, synchronisation and data transfer to the extent that Nemesis has. Most kernels (such as Mach [Accetta86] or Chorus [Rozier90]) provide blocking synchronisation primitives for kernel threads and message passing for inter domain communication. Nemesis has no kernel threads and relies on user space functionality for data transfer. This difference is addressed in more detail in chapter 5. 4.9 Evaluation To examine the ....

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrmann, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser. Overview of the CHORUS Distributed Operating Systems. Technical Report Technical Report CS-TR-90-25, Chorus Systemes, 1990. (pp 8, 70)

....5.2 Chorus Chorus is an object oriented message passing based distributed operating system that utilises a microkernel. A process is Chorus is called an actor. An actor can have multiple threads of execution, and utilises ports and messages to allow processes to communicate with each other [Rozier et al. 92] The Amadeus Project [O Connor et al. 94] follows with Chorus object oriented flavour, hence process (actor) migration on Chorus, is performed by three modules: kernel, transport and policy. The kernel module is responsible for encapsulating the state information of migrating processes and ....

....Chorus, is performed by three modules: kernel, transport and policy. The kernel module is responsible for encapsulating the state information of migrating processes and for re establishing these processes on other nodes using this state . and] for providing load information to policy modules [Rozier et al. 92] The policy module is the entity that (using several criteria) decides to migrate a process. Finally, the job of actually transferring the process is performed by the transport module. To migrate a process in Chorus: The policy module, after certain criteria are met (with the information ....

M. Rozier, V. Abrossimov, F. Armand, M. Gien, M. Guillemont, F. Hermann and C. Kaiser. Chorus.(Overview of the Chorus Distributed Operating System). USENIX Workshop on Micro-Kernels and Other Kernel Architectures, April.

....protocol implementation. Finding solutions to avoid or optimize copies is a constant concern of operating system designers. For instance, copy on write [12] was the technique which made message passing efficient enough to allow operating systems to be designed based on a micro kernel architecture [30, 31]. Buffers are needed when different modules or layers written independently for modularity reasons have to cooperate together at run time. This cause of overhead has been clearly demonstrated by Thekkath and Levy in their performance analysis of RPC implementations [36] Recent proposals in the ....

V. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrmann, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser. Overview of the Chorus distributed operating system. In USENIX - Workshop Proceedings - Micro-kernels and Other Kernel Architectures, pages 39--70, Seattle, WA, USA, April 1992.

....However, there are other functional factors that increase the number of contexts that a TLB must contain, and solutions aimed at the L1 TLB may be insufficient in these cases. The first functional trend is the distribution of operating systems across several contexts due to the use of microkernels [20]. This will increase the minimum number of contexts that a TLB must contain to provide the same level of functionality that a monolithic kernel provides. For example, a file system call can involve several processes (the file system server and the pager) in a microkernel based OS. The second ....

Mike Rozier et al. Overview of the CHORUS distributed operating system. In Proceedings of the USENIX Workshop on Micro-kernels and Other Kernel Architectures. USENIX, April 1992.

....Limited Code Re Use The software architecture of a system also plays a key role in code re use. Structuring a software system in terms of components is now a well recognized strategy to achieve code reuse. Notably, in the OS field, this structuring technique has lead to micro kernel architectures [2, 17, 12]. In this OS architecture, each component (or server) corresponds to a domain boundary. However, communication across this boundary introduces overhead. Because the software components are directly mapped into protected entities, their granularity impacts system performance. The OS architect thus ....

....Specifically, if the building blocks have not been clearly staged, policies and mechanisms may be intertwined. As a result, it becomes difficult to extend either mechanisms or policies. Finally, existing approaches to extending OSes enable new components to be added via modules or servers [3, 17]. However, other than memory protection, they do not offer any guarantees regarding the behavior of these new components. This limitation can have disastrous consequences considering the widespread nature of appliances. 3 A New Approach Based on Domain Specific Languages The common thread of our ....

V. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrmann, C. Kaiser, S. Langlois, P. L'eonard, and W. Neuhauser. Overview of the Chorus distributed operating system. In USENIX - Workshop Proceedings - Micro-kernels and Other Kernel Architectures, pages 39--70, Seattle, WA, USA, April 1992.

....If independent parties can work together effectively, then surely sub groups within a development group are also well served. Micro kernels and protocol stacks are two important illustrative examples of efforts to develop suitable interfaces in Unix. A micro kernel such as Mach [1] or Chorus [11] divides the operating system into two parts: a core, typically responsible for providing a virtual memory; and processing service, and the remainder of the operating system services that run within the framework provided by the core. In the case of Mach and Unix, as a figure of merit, the core is ....

Marc Rozier, Vadim Abrossimov, Francois Armand, Ivan Boule, Michel Gien, Marc Guillemont, Fr'ed'eric Herrmann, Claude Kaiser, Sylvain Langlois, Pierre L'eonard, and Will Neuhauser. Overview of the chorus distributed operating system. Technical Report CS/TR-90-25, Chorus syst`emes, April 1990.

....itself as a tendency towards monolithic system implementations which increasingly defy adequate testing and verification, and hinder improvements especially those not conceived within the monolithic framework. In recent years, micro kernels in systems such as Mach [ABG86, RBF89] and Chorus [RAA90] have emerged as a response to the monolithic implementations of operating systems. However, little has been done to tackle the monolithic filing service portion of most kernels. Adding any new features to a filing environment is usually a daunting task which frequently requires reimplementation ....

Marc Rozier, Vadim Abrossimov, Francois Armand, Ivan Boule, Michel Gien, Marc Guillemont, Fr'ed'eric Herrmann, Claude Kaiser, Sylvain Langlois, Pierre L'eonard, and Will Neuhauser. "Overview of the CHORUS Distributed Operating System." Technical Report CS/TR90 -25, Chorus syst`emes, April 1990.

....on massively parallel environments. This is because each processing unit must communicate with another over a network which has a higher cost of communication [CAP93] Some distributed environments s are Berkeley s NOW [CULL97] MOSIX [BARA98] Amoeba [TANE91] Sprite [OUST88] V [CHER88] Chorus [ROZI92], Globe [STEE97] Beowulf [RIDG97] and RHODOS [DePA95] The type of parallel execution that needs to be performed will most certainly play an important part in determining what type of parallel execution environment is chosen. The particular application may be either computation oriented, ....

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrman, C. Kaiser, S. Langlois, P. Lonard and W. Neuhauser. "Overview of the Chorus Distributed Operating System", Proceedings of the USENIX Workshop on Microkernels and Other Kernel Architectures, pp39-69, April 1992.

No context found.

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrman, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser. Overview of the CHORUS distributed operating system. Proceedings of the USENIX Workshop on Micro-Kernels and Other Kernel Architectures, pp. 39--69. USENIX Assoc., Berkeley, CA, 1992.

No context found.

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrmann, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser. Overview of the CHORUS Distributed Operating System. Technical Report CS-TR-90-25, Chorus Systems, 1990.

No context found.

M. Rozier, V. Abrossimov, F. Armand, L. Boule, M. Gien, M. Guillemont, F. Herrman, C. Kaiser, S. Langlois, P. L eonard, and W. Neuhauser. Overview of the Chorus distributed operating system. In Proceedings of the USENIX Workshop on Microkernels and other Kernel Architectures, pages 39--69, Seattle, WA, USA, April 1992.

No context found.

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrmann, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser. Overview of the chorus distributed operating systems. In Proceedings of the USENIX Workshop on Micro-Kernels and Other Kernel Architectures, pages 39--70, April 1992.

No context found.

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrman, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser. Overview of the Chorus Distributed Operating System. In Workshop on Micro-Kernels and Other Kernel Architectures, pages 39--70, Seattle, WA, 1992.

No context found.

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrman, C. Kaiser, S. Langlois, P. L eonard, and W. Neuhauser. Overview of the Chorus distributed operating system. In Workshop on Micro-Kernels and Other Kernel Architectures, pages 39--70, Seattle WA (USA), 1992.

No context found.

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrmann, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser, "Overview of the CHORUS Distributed Operating Systems," Tech. Rep. CSTR -90-25, Chorus Systems, 1990.

No context found.

Rozier, M., Abrossimov, V., Armand, F., Boule, I., Gien, M., Guillemont, M., Herrman, F., Kaise, C., Langlois, S., Leonard, P. and Neuhauser, W. Overview of the Chorus distributed operating system. In Proceedings of the Micro-kernels and Other Kernel Architectures Workshop, Seattle, Washington, USENIX, 39-69, 1992. 183

No context found.

M. Rozier, V. Abrassimov, F. Armand, M. Boule, M. Gien, M. Guillemont, F. Herrman, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser. Overview of the Chorus distributed operating system. In Usenix symposium on micro-kernels and other kernels architectures, April 1992.

No context found.

M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrmann, C. Kaiser, S. Langlois, P. Lonard, and W. Neuhauser. Overview of the CHORUS distributed operating systems. Technical Report CS/TR-90-25, Chorus Systmes, April 1990.

No context found.

Marc Rozier, Vadim Abrossimov, Francois Armand, Ivan Boule, Michel Gien, Marc Guillemont, Fr'ed'eric Herrmann, Claude Kaiser, Sylvain Langlois, Pierre L'eonard, and Will Neuhauser. "Overview of the CHORUS Distributed Operating System." Technical Report CS/TR-90-25, Chorus syst`emes, April 1990.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC