BYTE.com
Archives
Columns
Features
Print Archives
1994-1998
Special
BYTE Digest
Michael Abrash's Graphics Programming Black Book
101 Perl Articles
About Us
How to Access BYTE.com
Write to BYTE.com
Advertise with BYTE.com
Newsletter
Free E-mail Newsletter from BYTE.com
Jump to...
Columns:
Advanced Software and Technologies
BYTE Media Lab
Chaos Manor
Conference Reports
Features
Free Features
Gigglebytes
Letters to BYTE.com
Mr. Computer Language Person
New Products
Op/Ed
Portable Computing
Serving with Linux
The Upgrade Advisor
HOME
ABOUT US
ARCHIVES
CONTACT US
ADVERTISE
REGISTER
 European Telecoms Brace for Change
June 1997 / International Features / European Telecoms Brace for Change
A highly competitive setting is unfolding, scornful of long-established alliances and full of rapidly evolving, heterogeneous platforms.
Dick Pountain
The convergence of telecommunications and computing is happening fast. Although the telecoms industry has a history of state-run monopolies, adherence to worldwide standards, and sealed hardware systems, the full opening of the European telecoms market, scheduled for next year, is pushing telecoms equipment vendors in new directions.
A free, market-driven, highly competitive setting is on the horizon, scornful of long-established alliances and full of rapidly evolving, heterogeneous hardware and software platforms. This meeting of technologies is challenging software 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 can 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 follow 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 Wintel 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-restarting, 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 namespace 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 adding 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/
Chorus Systems
Saint-Quentin-en-Yvelines, France
Phone: +33 1 30 64 82 00
Fax: +33 1 30 57 00 66
Internet: http://www.chorus.com/
Lucent Technologies
Murray Hill, NJ, US
Phone: +1 908 582 3708
Internet: http://inferno.lucent.com/
HotBYTEs - information on products covered or advertised in BYTE
New Telecom OSes
New Telecom O\Ses
Chorus/Classix Galileo Inferno
Real-time * * *
Multithreaded * * *
Microkernel size About 12 KB About 15 KB N/A
Dynamically reconfigurable * * *
Hot-restartable *
Distribution-transparent * *
Java support * * Future
CORBA-compliant *
Compatible CPUs ARM, Intel x86, Motorola 68000, PowerPC, SPARC ARM, Hitachi SH, NEC-compatible CPUs ARM, HP-PA, Intel x86, Mips, SPARC
Primary target sector Telephone switches and PABXes, mobile phones, POS terminals, set-top boxes Set-top boxes, NCs, game consoles Set-top boxes, PDAs, portable terminals
* = yes; N/A = not applicable.
Swapping Chorus Program Units
illustration_link (21 Kbytes)
Dick Pountain is a longtime BYTE contributing editor based in London. You can contact him at dickp@bix.com.
    
Flexible C++
Matthew Wilson
My approach to software engineering is far more pragmatic than it
is
theoretical--and no language better exemplifies this than C++.
more...
BYTE Digest
BYTE Digest editors every month analyze and evaluate the best articles from Information Week, EE Times, Dr. Dobb's Journal, Network Computing, Sys Admin,
and dozens of other CMP publications—bringing
you critical news and information about wireless communication,
computer security, software development, embedded systems,
and more!
Find out more
BYTE.com Store
BYTE CD-ROM
NOW, on one CD-ROM, you can instantly access more than
8 years of BYTE.
The Best of BYTE
Volume 1: Programming Languages
In this issue of Best of BYTE, we bring together some of the leading programming language designers and implementors...
Copyright © 2005 CMP Media LLC,
Privacy Policy,
Your California Privacy rights,
Terms of Service
Site comments:
webmaster@byte.com
SDMG Web Sites:
BYTE.com,
C/C++ Users Journal,
Dr. Dobb's Journal,
MSDN Magazine,
New Architect,
SD Expo,
SD Magazine,
Sys Admin,
The Perl Journal,
UnixReview.com,
Windows Developer Network
|
|
