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).
Superuser
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."
Microkernel
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.