Unix International Inc says that its Unix System V.4 Enhanced Security Multi-processing – ES/MP – effort will coalesce various projects that have been under way using the standard System V.4 kernel since it was introduced to the world back at Unix Expo in 1989. The base System V.4.0 kernel was taken forward into a multi-processing […]
Unix International Inc says that its Unix System V.4 Enhanced Security Multi-processing – ES/MP – effort will coalesce various projects that have been under way using the standard System V.4 kernel since it was introduced to the world back at Unix Expo in 1989. The base System V.4.0 kernel was taken forward into a multi-processing release that supports up to 16 processors, System V.4 MP. At the same time, but separately, a Unix kernel with multi-level security enhancements, System V.4.0 MLS, was reworked to comply with the US government Orange Book B2 security requirement – with B3 extensions – emerging as System V.4.1 ES (though it hasn’t really gone out to end users yet). A massive amount of effort went into these parallel developments, according to Nick Price, technical director of Unix International Europe. Although System V.4 MP was the first technical success for the Unix International technology committees, Price says System V.4.1 ES should be regarded as Unix International’s technological lynchpin for the future. System V.4.1 ES involved a complete rearchitecting of the System V.4.0 kernel – to make it more robust for a start – and it now also embraces dynamic loading. Once dynamic loading was incorporated as a working feature – enabling operating system components, such as drivers, X Window and file systems, to be configured independently – the idea of a modularised, desktop operating system fitting into 4Mb RAM became a possibility, and work began on System V.4.2 (known as Destiny).
Indeed, the System V.4.1 ES work cleared out much of CPU-specific code that had crept into System V.4.0, resulting in what is now a clean implementation environment, according to Price. System V.4.1 ES also removes the concept of a superuser from Unix. Although the convention itself hasn’t been stripped out of the operating system entirely, the need for it has been all but eliminated. Unix now provides the user with access based upon the least privileges he or she requires to perform their tasks. So while superuser still resides in Unix, it is no longer needed to be able to handle system administration, for example. If System V.4.1 ES was pulled by US government security requirements, then System V.4.2 was pushed out of that effort. System V.4.2 went from a first snapshot last November to an end user product which is due by October-November this year. With System V.4.1 ES as the generic source base for all future products, Unix International’s goal is to reduce time to market with each technology release and push the operating system on into the commercial market. System V.4.1 ES, System V.4.2 and System V.4MP will converge in System V.4.2 ES/MP. It includes B2 security with B3 extensions, support for up to 32 CPUs, System V.4.2’s modularity and, by the time a full release comes to market, should include compliance with the next release of X/Open Co Ltd’s portability guide, XPG4. As well as providing a multi-threading kernel – where processes are allocated across the available CPUs – System V.4.1 ES/MP will, more importantly says Price, also support user-level Threads.
By William Fellows
The drawback of multi-threading is that it only enables whole processes to run on individual CPUs and is unsuited for particularly large applications. If, for example, an overnight batch file runs on a multi-threaded, multiprocessing system, the task (process) is still only available to one CPU, which means the rest of the processors will probably remain idle during that time. Break processes down into smaller sub-components – known as Threads – and these individual tasks can be distributed across CPUs (and therefore distributed networks). To encourage developers to write more modular software that can take advantage of systems that support Threads – a Thread can be any part of an application or program that is not dependent on the result or outcome of another (that can be treated as a task in its own right) – Posix has a committee working on a Threads application programming interface standard. PThreads, or P1003.4a, is expected b
y the end of this year, and Price says System V.4.1 ES/MP will conform to it as and when it is ratified. Pthreads itself is a set of C routines, a library of requirements for system calls and functions a Thread can recognise. Threads can run on uniprocessor systems as well as multiprocessors, but can obviously be employed to greater advantage on the latter. It is particularly applicable to large database and transaction processing systems, says Price, which are often composed of very large applications and tasks. Another advantage of Threads is that the fast emerging object model fits nicely on to it. Each thread – with its associated method (location address, data route and other information) – can be regarded as an object in an object-oriented system. One of the problems with many systems as presently marketed, observes Price, is that companies with products that comply with the basic Posix 1003.1 interface standard promote their products as open systems. The Posix interface is a collection of some 103 C language calls to the kernel that a product must observe to win compliance. While operating systems as distinct as Unix System V.4 and DEC’s OpenVMS embrace the Posix standard, each has thousands of other calls beyond the specific Posix requirement, says Price, which means that it is not sufficient just to convert an application to Posix and assume that it will then run on any Posix-compliant system, because it won’t. It is inconceivable that a developer would use just 103 calls in any case, says Price, warning that P1003.1 alone doesn’t mean portability. The problem is just as apparent within the different Unixes that abound. Price recounts the experience of one Unix International client that bought a range of open systems equipment supporting Posix, assuming that applications would be portable across the mix of System V.4, Ultrix, HP-UX and AIX environments that came with the kit that it had hopefully purchased. Not only is it problematic (and doubly so for the user) to convert an application from AIX to System V.4 for example, but trying to manage the different environments on a network is even more difficult. Outside its base System V.4.0 kernel activities, Unix International is still hard at work on a microkernel version of Unix, which will it hopes will broaden the attraction of Unix to the telecommunications market for example, with its embrace of real-time and parallel systems. It’s much easier for a company to run a standard operating system on a telephone switching system, says Price, because the systems management stuff has already been developed and can run on it too.
He argues that while the monolithic kernel maybe be sufficient for most of today’s operating system requirements, a microkernel incorporates things like replication and fault resilience, which standard system software doesn’t embrace. A microkernel uses interprocess communication and virtual memory and is able to split operating system functions across CPUs or distributed systems. It is a message-passing system rather than interrupt driven. Unix International (via Unix System Laboratories Inc) is using Chorus Systemes SA’s already established Chorus/Mix System V.4 microkernel as the basis of this work, although that’s no guarantee that future System V.4 releases will incorporate a microkernel. Stage one, according to Price, will be to investigate a microkernel version of System V.4.2 ES/MP – after which Unix System Labs may take a look at it. Unix International has real-time, parallel processing and object-oriented groups working on microkernel plans and is planning to produce a requirements document in each of these area in October. The groups are open to anyone.