Accent kernel

rdf:langString Accent kernel

rdf:langString Accent was an operating system kernel developed at Carnegie Mellon University (CMU). Accent was developed as a follow-on to the Aleph kernel developed at the University of Rochester, fixing several of its problems and re-targeting its hardware support for networks of workstation machines (specifically, the Three Rivers PERQ) instead of minicomputers. Accent was part of the at CMU which ran from 1981 to 1985. Development of Accent led directly to the famous Mach kernel. The original Aleph project used data copying to allow programs to communicate. Applications could open ports, which would allow them to receive data sent to them by other programs. The idea was to write a number of servers that would control resources on the machine, passing data along until it reached an end user. In this respect it was similar in concept to Unix, although the implementation was much different, using messages instead of memory. This turned out to have a number of problems, notably that copying memory on their Data General Eclipse was very expensive. In 1979 one of the Aleph engineers, Richard Rashid, left for CMU and started work on a new version of Aleph that avoided its problems. In particular, Accent targeted workstation machines featuring a MMU, using the MMU to "copy" large blocks of memory via mapping, making the memory appear to be in two different places. Only data that was changed by one program or another would have to be physically copied, using the copy-on-write algorithm. To understand the difference, consider two interacting programs, one feeding a file to another. Under Aleph the data from the provider would have to be copied 2kB at a time (due to features of the Eclipse) into the user process. Under Accent the data simply "appeared" in the user process for the cost of a few instructions sent to the MMU. Only if the user process changed the data would anything need to be copied, and even then, only the portions of the data that actually changed. Another problem in Aleph was that its ports were identified by unique ID's that were assigned sequentially. It was simple for a program to "guess" them, thereby gaining access to resources on the computer that it had not been granted. This made the Aleph system rather insecure. To address this, Accent made the port ID's internal to the kernel only. Instances of a program opening ports were handed back different IDs, stored in a mapping in the kernel. Whenever a message was sent to the kernel for delivery, it would first check that the program had access to the port in question by comparing with the mapping table for that program. Guessing port numbers no longer worked, the program's port IDs gave no clue of the "real" IDs in the kernel, and any attempt to talk on one not explicitly handed out by the kernel was an error. Thus Accent's ports represented capabilities, granting rights to use resources as the result of being handed a valid port ID. This kind of capability system, using subject-specific identifiers for capabilities, is called a C-list system. After a few years the Accent project started looking less and less interesting. In the early 1980s many felt that future gains in performance would be made by adding more CPUs to machines, something the Accent kernel was not really equipped to handle. Adding to the problem was that a new generation of more powerful workstations were appearing, meaning that Accent would likely have to be ported to them anyway. Likewise Unix had grown into the operating system of choice for experimental work, both on operating system design, as well as a development platform for user applications. In order to address these changes, it was decided to end work on Accent and start again. The new system would use Accent's ports system within a Unix kernel, creating the famed Mach kernel. Some features of Accent: * Port capabilities * Copy-on-write virtual memory management * Distributed file management * Distributed process management * Protected message-based inter-process communication * Ability to run processes with different microcoded instruction sets.