soft
ware architects who must tie the two diverse realms together -- especially the designers of new telecom OSes.
Phones Talk to TVs
Over the past two decades, telcos have focused on convergence, completely abandoning their reliance on hard-wired technology in favor of software for their switches and exchanges. But today, the term
convergence
means that the software embedded in these devices needs to be made open enough to communicate with computers and consumer electronics devices, such as TV sets. The resulting challenge to the OS designer is acute, as the software needs to control a variety of media, connection methods, and endpoints.
Data sources can range from a voice or video phone, to a Web server, to a cable TV station, and the connection methods used can vary from an ordinary phone modem, to ISDN, to the Internet, to asynchronous transfer mode (ATM). At the receiving end, the hardware might be a cell-phone handset, a PDA, a PC or network computer (
NC), a game console, or a TV set-top box. Keeping all these bases covered imposes tough conditions on an OS.
None of the mainstream desktop OSes can fulfill all -- or even the majority -- of these conditions, and so a
new generation
of distributed OSes is emerging. Examples include Chorus/Classix, Acorn's Galileo, and Lucent's Inferno.
Given the standards-oriented character of the telecomms industry, it's no surprise that a new standard software architecture is being proposed for a future intelligent telecomms network. This standard, called TINA (for Telecommunications Information Networking Architecture), is based on extensions to the ISO's Open Distributed Processing (ODP) and the Object Management Group's (OMG's) CORBA-2 object standards.
One of the aims of TINA is to promote distribution transparency; that is, to relieve the designers of objects from having to know the final location of those objects. A TINA environment should be transparent with regard to access (e
.g., different data representations, network protocols, and CPUs); location; failure; migration (i.e., change of location); concurrency, and persistence.
At the Geneva Telecom '95 trade fair in October 1995, a group made up of 12 European companies announced a three-year, $17 million joint project, called ReTINA (for Real-Time TINA), to produce the first TINA-compliant distributed processing environment (DPE) as an open platform for twenty-first-century telecomms. The companies that are involved in the ReTINA project include British Telecom, Germany's Siemens, Norway's Telenor, and Alcatel, Chorus Systems, and France Telecom, all from France. One of the project's primary goals is to develop two real-life demonstrator systems running over ATM networks: a broadband virtual private network and a distributed information service.
A Chorus of Objects
One of the OS platforms that the ReTINA project will use is Chorus/Classix, a microkernel-based, distributed, object-oriented, real-time
OS that was developed by Chorus Systems (Saint-Quentin-en-Yvelines, France). Originally developed from research at France's INRIA national research institute, Chorus was one of the first OSes to be based on a microkernel with integrated message-passing abilities (see "The Chorus Microkernel," January 1994 BYTE). At first, Chorus Systems used this microkernel to support a distributed Unix implementation. But in recent years the firm has switched its attention more to the embedded telecoms field, in partnership with Alcatel, which uses Chorus in its switches.
Chorus is a completely modular system that enables a user to build custom OS configurations by adding modules to the basic microkernel; currently there are kernels for the Intel x86, Motorola 68000, SPARC, and PowerPC processor families. Chorus/Classix provides two alternative microkernels: the original microkernel, called the Chorus Core Executive; and an even-further-stripped-down Micro Core Executive, which occupies just 10 KB of memory and so ca
n be embedded in consumer devices, such as telephone handsets.
The Chorus Core Executive supports multiple independent multithreaded applications, called "actors," with dynamic memory management. In contrast, the Micro Core Executive supports only a single, multithreaded actor using a static memory model.
To one of these kernels you can add one of two scheduler modules (a simple priority-based first-in/first-out [FIFO] module or one that supports multiple algorithms, including Unix time-sharing), one of three memory-manager modules (flat memory, protected memory, or full virtual memory), and a communications module that supports message-based interprocess communications (IPC). You can add many more modules to these basic functions -- from file systems, debuggers, and network protocols right up to a CORBA-2-compliant object request broker (ORB) called Chorus/Cool and a real-time Java OS called Chorus/Jazz.
The Chorus computing model is based on a number of abstractions. A node, or site, is a
unit of close-coupled computing hardware (e.g., a network workstation or a bus card). An actor, the unit of resource allocation (equivalent to a Unix process), can contain many internal threads (i.e., lightweight processes, as in Windows NT or OS/2), which are the units of program execution.
An actor is the smallest unit you can load onto a site, but the individual threads within an actor can be allocated to separate CPUs. Thus, Chorus supports both symmetric multiprocessing (SMP) and massively parallel processing (MPP). Each actor gets its own shared or protected address space and a set of "ports," the entities to which all IPC communications between actors are addressed. Ports act as globally named message queues that make communications within a Chorus location transparent.
Chorus also allows ports to migrate from one actor to another, which is how the OS supports dynamic reconfiguration. To replace one module with another without bringing the system down, an installation program needs to follo
w this sequence of steps (see the figure
"Swapping Chorus Program Units"
):
- Load the new actor into memory (but don't start it).
- Stop all the old actor's application threads.
- Collect the state of all objects in the old actor.
- Transmit this to the new actor.
- Migrate all ports from the old to the new actor.
- Start the threads of the new actor at the appropriate entry points.
- Delete the old actor from memory.
Another feature of Chorus ports is that you can group them together and then multicast messages to all members of such a named port group. This mechanism enables the hot-swapping of servers, because you can remove and insert ports into a group transparently to all message traffic sent to the group name.
Chorus also supports hot-restarting after a failure in a part of the system, via the notions of persistent actors and memory regions. When a fault occurs, Chorus's restart module can kill off all actors except those marked
as persistent, and it can also clear all data not marked as persistent. It then restarts all the persistent actors at a predefined entry point; if corrupt data was the cause of the error, this might restore correct execution.
One way to use this mechanism is to implement an escalating ladder of restart policies. A critical application might first try to restart with clean data; then, if that doesn't work, Chorus reloads all its actors (including the persistent ones). It resorts to a full-kernel restart only if these steps fail to correct the fault.
Support for legacy OSes under Chorus is via two routes. Chorus/Classix supports so-called personalities that export the API of an existing OS. Personalities currently offered include SCR4 Unix and Posix, with a Windows NT module due during the second quarter of this year. The other route is via the Chorus/Cool ORB, which lets a developer transparently distribute object-based applications across a heterogeneous network that includes Unix, Windows 95/NT,
and Chorus machines. Chorus Systems claims that its ORB, which has a small memory footprint (around 100 KB), is two to three times faster than any other real-time ORB on the market.
Acorn's Galileo
U.K. computer manufacturer Acorn has recently reinvented itself, in collaboration with its new partner, Oracle, as a designer of NCs. A part of this transformation will involve the launch of a new OS called Galileo, which is aimed specifically at networked interactive multimedia devices of all kinds. Acorn's Network Computers division developed the NC architecture that the company licenses to Oracle's NCs, while another division, Acorn RISC Technologies (ART), is working on Galileo and is scheduled to begin releasing modules during the fourth quarter of this year.
The greatest strength of Acorn's ARM-based range of PCs and its RISC OS has always been their multimedia processing power; they sported software codecs capable of handling real-time video streams back in the days when Winte
l PCs struggled to display a GIF. RISC OS, which has a built-in scalable, antialiased font-rendering engine, has always supported fully dynamic memory and screen-resolution management. Galileo will inherit these strengths from RISC OS but incorporate them into a modular, multiplatform OS built around a microkernel with a hardware-dependent, isolating hardware abstraction layer (HAL).
The HAL is 95 percent written in high-level language, so porting it to a new CPU is a short process. The first Galileo release will be for the ARM processor family, followed by versions for low-power-consumption RISC processors, such as the Hitachi SH series and the NEC V30.
Acorn spokesman Mark Phillips says that "we can produce Galileo for Intel CISCs when one of our customers requires it, but Intel processors don't have much of a presence in low-power consumer electronics, such as mobile phones." Galileo is also intended for set-top boxes, game consoles, and other consumer devices, such as digital cameras and NCs.
A Galileo system is composed from many small sharable modules that you can add and remove either at build time or at run time -- its smallest configuration is around 15 KB, which is ideal for embedding in hand-held devices. Like RISC OS, Galileo can run from ROM, and it supports systems that use any mixture of ROM, RAM, and flash RAM. (Acorn has developed a FlashDisplay technology that uses flash RAM to cache frequently accessed Web pages for faster browsing.)
The Galileo kernel supports multithreaded execution and SMP. It also features new quality-of-service (QoS) scheduling algorithms that dynamically manage the allocation of system resources.
For example, suppose you're simultaneously saving a spreadsheet, downloading a Web page, and printing a word processor document in the background while listening to music from a CD. Galileo establishes the level of service required by each of these tasks and allocates resources appropriately. For example, the CD audio stream requires a certain amount
of CPU time to avoid dropouts and sound degradation. Once they're allocated, Galileo does not divert these resources without first notifying you; so if you try to open, say, a video-phone link, Galileo might tell you this cannot be accomplished given the existing resources and then ask you which tasks you want to suspend.
Galileo will be supplied with network-protocol modules to support TCP/IP, UDP, NetBEUI, and AppleTalk; hardware drivers for modem, Ethernet, ISDN, and ATM; and graphics modules to provide systemwide support for GIF, TIFF, and JPEG. An HTML 3.2-compliant browser, mailer, and newsreader with Java support via a just-in-time compiler are also promised.
For manufacturers of game consoles and network TVs, Galileo features antialiased text and built-in anti-twitter software to produce a steady, readable display, even on an interlaced TV screen. Compared to Chorus/Classix, Galileo is aimed at a less mission-critical, more consumer-oriented market, so it does not try to provide any hot-r
estarting, hot-swapping, or other fault-tolerant capabilities.
Blazing Inferno
Lucent Technologies, the telephony and networking company, offers Inferno, its own contender for the telecom-aware OS market. Developed by Lucent's R&D division, the Computer Sciences Research Centre at Bell Labs, Inferno is a distributed OS aimed at the same market sectors -- advanced telephones, PDAs, TV set-top boxes, and NCs -- as Galileo and Chorus/Classix. Like its competitors, Inferno is portable across different processor families (it currently supports Intel, SPARC, Mips, ARM, HP-PA, and AMD 29000 processors), but it's also capable of running as a user application under other OSes, notably Windows 95 and NT, Unix, and Bell Labs' Plan 9.
Inferno employs a fairly small kernel so that it can run useful applications on a device with 1 MB of memory. A typical Inferno system consists of a large number of inexpensive terminals (e.g., NCs, PDAs, and set-top boxes) running Inferno as their native
OS, connected to a small number of powerful servers that run Inferno under (or alongside) their native OS, such as Unix or NT. This allows Inferno to access existing databases and transaction systems. Inferno applications can then run on the client, server, or both.
Inferno is a modular system that applications can reconfigure at run time to use different modules according to the current context. For example, a teleshopping application might use a text-only still photo or a full-motion video display, depending on whether the client is connected via a modem, ISDN, or an ATM link.
The design of Inferno draws heavily from Bell Labs' experimental Plan 9 system. All resources available to the system -- from data files to hardware devices -- are treated like files that can be read or written to, and all are organized into a forest of directory trees.
Each terminal user has a private namespace and can attach resources (e.g., disks and printers) physically located on remote machines to this namespac
e so that they behave as local resources. Inferno's own communications protocol, called Styx, ensures that all these resources appear in a uniform way to the user. Hardware devices, such as modems and printers, appear as directory folders containing two files, called
data
and
ctl
. Styx operates at a higher level than (and hence can be carried over) TCP/IP, ATM, and various serial protocols, including PPP and SLIP.
Developers write Inferno applications in a new language called Limbo, which resembles Java in certain respects: It, too, is compiled into bytecodes that get interpreted on a virtual machine, and therefore it's inherently portable to different CPU instruction sets. There's also an on-the-fly Limbo compiler that can turn bytecodes into native code, which runs almost as fast as C code. Also like Java, Limbo has a garbage collector and restricts the use of pointers to reduce the incidence of memory errors; this is particularly important, since lightweight Inferno clients may well
have no hardware memory protection.
Limbo differs from Java in several ways, too. It's strongly typed, with a syntax based on C and Pascal, and it doesn't use object-oriented constructs, although it has abstract data types. Like Java, it supports multiple concurrent threads, but Limbo employs a more elegant synchronization mechanism -- named channels based on communicating sequential processes -- in place of Java's wait/notify monitors.
To create distribution transparency, Inferno and Limbo present the same set of abstractions and resources to any application -- no matter where it's running, locally or remotely. When running as a native OS, it provides its own device drivers, network interface, and simple windowing graphics library. When running under Windows NT or Unix, however, it maps these services into host services, such as native Windows graphics and Winsock, or the X Window System and sockets. Inferno uses standard public-key mechanisms to provide encryption for security purposes, and add
ing new resources to a namespace is an operation that requires authentication from a trusted authority.
A Fresh Start?
Today, no new desktop OS stands a chance of getting a significant share of the market in the near future. However, in the brave new world of smart telecoms networks and network PCs, it's still possible for new technologies to get a foothold.
The three contenders outlined here show just how far OS design has advanced. The lightweight, scalable, modular, reliable, and transparent architectures of Chorus/Classix, Galileo, and Inferno show what's possible in an emerging market that will be huge.
Where to Find
Acorn RISC Technologies, Ltd.
Cambridge, U.K.
Phone: +44 1223 725000
Fax: +44 1223 254262
Internet:
http://www.acorn.co.uk/
European Telecoms Brace for Change
