The Chorus Team. Overview of the Chorus distributed operating system. In USENIX Workshop on Microkernels and other KernelArchitectures, Seattle, WA, 1992.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....It then calls a function (TbxAline) that analyses the trap word and starts a new thread at the address of the routine corresponding to the A line in MacOS. The new thread stack pointer is set at the application stack top. In order to keep track of the message number, we use the software register [8] associated with the started thread. When the routine ends, a function is called that creates a new message containing the may be modified registers and the software register number. This message is sent to the AlinePort and the thread ends. 5.3.3. Resuming the application The Server thread ....

Chorus Systmes, Overview of Chorus Distributed Operating Systems, from Chorus v.3 Programmer's reference Manual.

....achieved. 2.1. Porting Chorus on Mac Hardware The target machine is a Macintosh II CX. It is based on a MC68030 and many added chips. We used the Chorus sources for a Tadpole TP33M that is also based on the MC68030 chip. 2.1.1. Chorus kernel design As shown in Figure 1 below, the Chorus kernel [9] is composed of four independent elements: The supervisor dispatches interrupts, traps and exceptions delivered by the hardware. The real time executive controls the allocation of the processor. The virtual memory manager is responsible for manipulating virtual memory hardware and ....

Chorus Systmes, Overview of Chorus Distributed Operating Systems, from Chorus v.3 Programmer's reference Manual.

....be used in this context. One of properties of Unix is that a process in kernel mode can directly access it own user level address space. While alternative implementations of Figure 1. Statically linked shared libraries using recursive mapping. 4 Unix on micro kernels such as Mach[1] and Chorus[4] are possible, the native Unix approach is tried and proven and is clearly efficient. One of the problems with implementing Unix as a user level program in, for example, Mach is that the kernel resides in a different address space from the processes. This makes it difficult to directly access ....

Chorus Systems "Overview of the CHORUS Distributed Operating Systems", Computer Systems - The Journal of the Usenix Association, 1(4), 1990.

....in which the distinction between long and short lived data is apparent. To support the implementation of various different store architectures, managers have control over the virtual memory system in a similar manner to external pagers in micro kernel operating systems such as Mach [1] and Chorus [12]. 3.3 Problems with the Current Implementation From our experience with the initial version of the Grasshopper system, we feel that we have made significant progress towards the goals we set out to achieve. However, through our porting efforts, a number of problem areas have been identified. ....

....of abstractions such as threads, address spaces, and inter process communication. These abstractions can be composed to build user level servers that implement common services such as file systems, processes, and virtual memory. Examples of micro kernel architectures include Mach [1] Chorus [12], Amoeba [35, 45] V [10] Choices [9] Psyche [42] L3 L4 [28, 29] and Arena [34] The most notable effect of the micro kernel design is to separate the implementation of the system into smaller, more manageable pieces in the form of the kernel and the user level servers. This arrangement ....

Chorus-Systems, "Overview of the CHORUS Distributed Operating Systems", Computer Systems, 2(4), 1990.

....container. Grasshopper provides two facilities that allow the transfer of data between containers: mapping and invocation. Container mapping allows data in a region of one container to be viewed within a region of another container. Unlike the memory mapping mechanisms provided by other systems [1,2,22] containers may be arbitrarily (possibly recursively) composed providing considerably enhanced flexibility and performance [15] Invocation is the process whereby a locus moves between containers. During invocation, a locus may supply a parameter block which contains data to be used in the ....

Chorus-Systems "Overview of the CHORUS Distributed Operating Systems", Computer Systems - The Journal of the Usenix Association, Vol 1, No 4., 1990.

....in which the distinction between long and short lived data is apparent. To support the implementation of various different store architectures, managers have control over the virtual memory system in a similar manner to external pagers in micro kernel operating systems such as Mach [3] and Chorus [12]. 2.8# Problems with the Current Implementation From our experience with the initial version of the Grasshopper system, we feel that we have made significant progress towards the goals we set out to achieve. However, through our porting efforts, a number of problem areas have been identified. ....

Chorus-Systems, "Overview of the CHORUS Distributed Operating Systems", Computer Systems - The Journal of the Usenix Association, (Vol 1 No 4.), 1990.

....operating systems restrict the mapping of memory to a single level. Both VMS [24] and variants of Unix (such as SunOS) provide the ability to share memory segments between process address spaces, and a separate ability to map from disk storage into a process address space. Several other systems [7, 8, 28, 31] provide the notion of a memory object, which provides an abstraction over data. In these systems, memory objects can be mapped into a process address space, however memory objects and processes are separate abstractions. It is therefore impossible to directly address a memory object, or to ....

Chorus Systems "Overview of the CHORUS Distributed Operating Systems", Computer Systems - The Journal of the Usenix Association, 1(4), 1990.

....an access fault, and a set of interfaces which allow managers to arrange the hardware translation tables in such a way that the required data is visible at an appropriate address in the container. Thus managers provide user level virtual memory management in common with other operating systems [2, 7] The Grasshopper kernel treats loci and the data accessed by them during computation as the unit of recovery. Loci are able to snapshot the state of their computation at any time, a task which is co ordinated by the kernel and draws on services provided by the managers to snapshot user level data. ....

Chorus-Systems "Overview of the CHORUS Distributed Operating Systems", Computer Systems - The Journal of the Usenix Association, Vol 1 No 4., 1990.

....transfer of data between containers. The purpose of container mapping is to allow data to be shared between containers. This is achieved by allowing data in a region of one container to be viewed within a region of another container. Unlike the memory object mechanism provided by other systems [15, 16], containers may be arbitrarily (possibly recursively) composed which provides considerably enhanced flexibility and performance [28] Since any container can have another mapped into it, it is possible to construct a hierarchy of container mappings as shown in Figure 1. The hierarchy of container ....

Chorus Systems "Overview of the CHORUS Distributed Operating Systems", Computer Systems - The Journal of the Usenix Association, vol 1, 4, 1990.

....group Fig. 2: Group Message Distribution in the V Kernel In Chorus co operation among processes is based on message passing between processes. Messages are exchanged via ports, where a process can have one or more ports. A port can be a member of a group and receive messages addressed to the group [16]. Groups on the operating system level can be managed by a group server. The group server maintains a data base of all groups containing their addresses and a membership list. In a distributed approach each member keeps a membership list. In this case each new member is registered with every ....

Chorus Systems: "Overview of the CHORUS Distributed Operating Systems", CS/TR-9025. 1, Chorus Systems, Saint-Quentin-En-Yvelines Cedex, 1991.

....under ESPRIT Project 6603 OUVERTURE . y This paper also appears in the proceedings of the SIGOPS 94 European Workshop, Dagstuhl, Germany, September 1994. In this paper we present new kernel support for monitoring and debugging tools within the CHORUS distributed micro kernel architecture [Cho92]. This support has enabled us to port two application level tools on CHORUS: PATOC [Her91] a real time monitor, and CDB [Rug94] a debugger with an execution replay facility for distributed applications running on top of CHORUS. The work is an actual example of a cooperation between a system ....

Chorus Team. Overview of the Chorus distributed operating system. In USENIX Workshop on Micro Kernels and Other Kernel Architecthres, Seattle (USA), 1992.

.... be transparent to the user and the programmer and should allow concurrent execution of parallel processes while maintaining dynamic load balancing [Douglis and Ousterhout, 1991; Goscinski, 1991] This facility is available in Sprite [Douglis and Ousterhout, 1991] Emerald [Black et al. 1987] Chorus [Chorus Systems, 1990] and RHODOS [De Paoli, 1993] amongst others. 4.5 Reliability and Availability The possibility of increased reliability is a promised feature of distributed processing. Due to the nature of distributed processing there is also the possibility of increased availability. This section addresses ....

Chorus Systems (1990) Overview of the Chorus Distributed Operating System, Technical Report CS/TR-90-25, Chorus Systems.

....other. Work on such opportunistic embellishments remains to be done. Meanwhile, we are actively introducing the versions that have been successfully prototyped into everyday use as and when the opportunity presents itself. Esprit III Project N 0 6603 18 Public OUVERTURE OU TR 94 3 References [1] R. Lea, C. Jacquemot, E. Pillevesse, COOL: System Support for Distributed Programming , Communications of the ACM, Vol. 36, N. 9, September 1993. 2] M.A. Goulde, Tomorrow s Microkernel based Unix Operating Systems , Open Infomation Systems, Vol. 8, N. 8, August 1993. 3] HyperDesk ....

....interactions in Chorus MiX V.4, which is a microkernel based multi server implementation of UNIX SVR4, validated this approach. COOL IDL forms an integral part of the COOL (CHORUS Object Oriented Layer) framework [3, 4] and hence the code generated from COOL IDL specifications uses Chorus IPC [1] based facilities provided by the COOL generic runtime for remote object invocation. However, it is possible to use an alternate IPC mechanism like sockets by modifying the COOL generic runtime library if one so desires. 2 COOL IDL Language The design of COOL IDL is based on the belief that the ....

Chorus Team. "Overview of the Chorus Distributed Operating System", USENIX Workshop on MicroKernels and Other Kernel Architectures, Seattle (USA), April 1992.

....on an access fault, and a set of interfaces which allow managers to arrange the hardware translation tables in such a way that the required data is visible at an appropriate address in the container. Thus managers provide user level virtual memory management in common with other operating systems [2,7]. The Grasshopper kernel treats loci and the data accessed by them during computation as the unit of recovery. Loci are able to snapshot the state of their computation at any time, a task which is co ordinated by the kernel and draws on services provided by the managers to snapshot user level ....

Chorus-Systems "Overview of the CHORUS Distributed Operating Systems", Computer Systems - The Journal of the Usenix Association, Vol 1 No 4., 1990.

....distributed application on top of the CHORUS micro kernel. 1 Introduction An important challenge in the area of system development is to provide the user with a powerful development environment. For instance, a good set of debugging tools is essential. The CHORUS distributed operating system [4] currently provides the user with two specific debuggers: the KDB tool [3] for debugging the kernel itself, and an enhanced version of GNU s GDB tool [30] for debugging multi threaded programs running on top of the kernel 1 . However, CHORUS does not provide specific tools for debugging truly ....

Chorus Team. Overview of the Chorus distributed operating system. In USENIX Workshop on Micro Kernels and Other Kernel Architecthres, Seattle (USA), 1992.

....and a group ceases to exist when the last member leaves. Groups are managed by the system [3] In CHORUS co operation among processes is based on message passing between processes. Messages are exchanged via ports, a port can be a member of a group and receive messages addressed to the group [2]. 2.2 Group Support in the Transport System In the transport system group communication is supported by some data link, network and transport protocols. In LANs group communication depends on the ability of the underlying network to broadcast messages. The protocols standardised in IEEE 802.x ....

Chorus Systems, "Overview of the CHORUS Distributed Operating Systems", CS/TR-90-25.1, Chorus Systems, Saint-Quentin-En-Yvelines Cedex, 1991.

No context found.

The Chorus Team. Overview of the Chorus distributed operating system. In USENIX Workshop on Microkernels and other KernelArchitectures, Seattle, WA, 1992.

No context found.

The Chorus Team. Overview of the Chorus distributed operating system. In USENIX Workshop on Microkernels and other Kernel-Architectures, Seattle, WA, 1992.

No context found.

The Chorus Team. Overview of the Chorus distributed operating system. In USENIX Workshop on Microkernels and other Kernel-Architectures, Seattle, WA, 1992.

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