 |
Claims  |
|
|
Having thus described our invention, what we claim as new, and desire to
secure by Letters Patent is:
1. An apparatus for booting an object-oriented operating system comprising
a kernel program and a plurality of shared libraries containing
hardware-independent, object-oriented programs onto a computer system
comprising a plurality of hardware devices connected in a configuration,
the apparatus comprising:
(a) a processor;
(b) a volatile storage attached to and under the control of the processor;
(c) a non-volatile storage attached to and under the control of the
processor, the non-volatile storage having the kernel program, the
plurality of shared libraries and a hardware-specific boot image program
stored therein;
(d) boot image delivery means for loading the boot image program from the
non-volatile storage into the volatile storage;
(e) framework setup means for causing the processor to execute the boot
image program to load the kernel program from the non-volatile storage
into the volatile storage, to determine the configuration of the plurality
of hardware devices and to generate configuration data in a universal
format; and
(f) framework execution means for causing the processor to initialize the
kernel with the configuration data, to start a program which provides
paging between the volatile storage and the non-volatile storage and to
instantiate an object oriented file system from the shared libraries.
2. Apparatus as recited in claim 1, wherein the boot image program
comprises a plurality of boot files and wherein the apparatus includes:
(a) boot start means for determining which boot files stored in the
non-volatile storage comprise the boot image program and
(b) means for determining the configuration of the plurality of hardware
devices.
3. The apparatus of claim 2 wherein each of the plurality of boot files
comprises a file handle and wherein the framework execution means further
includes means for using file handles of the plurality of boot files
comprising the boot image program in the kernel program so that the kernel
program fits into a smaller part of the volatile storage.
4. Apparatus as recited in claim 1, including operating system support for
System 7, OS/2, DOS, and UNIX.
5. The apparatus of claim 1 wherein the framework setup means includes
means for generating a stack and wherein the framework execution means
includes means for providing a file system interface to the non-volatile
storage.
6. A method for booting an object-oriented operating system comprising a
kernel program and a plurality of shared libraries containing
hardware-independent, object-oriented programs onto a computer system with
a processor, a volatile storage attached to and under control of the
processor, a non-volatile storage attached to and under control of the
processor and a plurality of hardware devices connected in a
configuration, the non-volatile storage having the kernel program, the
plurality of shared libraries and a hardware-specific boot image program
stored therein and the method comprising the steps of:
(a) loading the boot image program from the non-volatile storage into the
volatile storage;
(b) executing the boot image program to load the kernel program from the
non-volatile storage into the volatile storage, to determine the
configuration of the plurality of hardware devices and to generate
configuration data in a universal format; and
(c) initializing the kernel with the configuration data, to start a program
which provides paging between the volatile storage and the non-volatile
storage and to instantiate an object oriented file system from the shared
libraries.
7. A method as recited in claim 6, wherein the boot image program comprises
a plurality of boot files and wherein the method includes the steps of:
(d) determining which boot files stored on the non-volatile storage
comprise the boot image program; and
(e) determining the configuration of the plurality of hardware devices.
8. The method of claim 7 wherein each of the plurality of boot files
comprises a files handle and wherein step (d) includes the step of using
file handles of boot files comprising the boot image program in the kernel
program so that the kernel program fits into a smaller part of the
volatile storage.
9. The method as recited in claim 6 including the step of supporting System
7, OS/2, DOS, and UNIX.
10. The method of claim 6 wherein step (b) includes the step of providing a
stack and wherein step (c) includes the step of providing a file system
interface to the non-volatile storage.
11. A booting framework stored on a computer-readable medium for booting an
object-oriented operating system comprising a kernel program and a
plurality of shared libraries containing hardware-independent,
object-oriented programs onto a computer system comprising a volatile
storage, a non-volatile storage and a plurality of hardware devices
connected in a configuration, the framework comprising:
(a) subclassable boot image class information comprising information
defining a data structure for holding references to a plurality of boot
program files and program code defining member functions for adding boot
program files to, and deleting boot program files from, the data structure
and a member function for checking that the plurality of boot program
files includes at least a hardware-dependent boot image delivery program
for loading the boot files from the non-volatile storage into the volatile
storage and a hardware-dependent boot setup program for loading the kernel
program from the non-volatile storage into the volatile storage, for
determining the configuration of the plurality of hardware devices and for
generating configuration data in a universal format; and
(b) non-subclassable boot execution class information including program
code for initializing the kernel with the configuration data, for
instituting paging between the volatile storage and the non-volatile
storage and for instantiating a file system object from the shared
libraries.
12. A booting framework as recited in claim 11 wherein the boot execution
class information includes system genesis program code for generating a
boot content server for managing files contained in the boot image
program.
13. A booting framework as recited in claim 12 wherein the system genesis
program code includes nublibrary program code having runtime routines,
runtime servers and shared system libraries for supporting the shared
libraries in the non-volatile storage.
14. A booting framework as recited in claim 13 wherein the boot execution
class information further includes program code for a boot conductor
program started by the system genesis program code and containing program
code that is responsive to the program code present in the boot image
program, the hardware configuration and the contents of the shared
libraries for instantiating a file object to allow access to the shared
libraries in the non-volatile storage.
15. A booting framework as recited in claim 14 wherein the boot conductor
program contains program code to creating a library searcher for searching
files in the non-volatile storage to locate shared libraries. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention is generally directed to an input/output architecture
for a computer system, and more particularly directed to an
object-oriented input/output architecture for a computer system.
2. Related Art
A typical computer includes an input/output (IO) system to interface with
peripheral devices which are connected to the computer. This IO system
serves as an interface between resources of the computer system and the
peripheral devices. This IO system also serves as an interface between
programs executing on the computer system and the peripheral devices.
IO systems are typically implemented using conventional
"procedure-oriented" software programming techniques (as opposed to
object-oriented or rule-based software programming techniques). As will be
appreciated, software programs produced using procedure-oriented software
programming techniques are often not easily extendible. Also, often such
software programs cannot be easily reused. Thus, conventional IO systems
are often not easily extendible, and the software associated with such IO
systems are often not easy to reuse.
Typically, an IO system is implemented such that it is specific to a single
operating system. The IO system responds to and correctly processes the IO
function calls which are associated with the operating system, but the IO
system does not have the capability to support any other operating
systems. There is a growing need for computers which support multiple
operating systems. Clearly, a computer which uses a conventional IO system
is at a disadvantage in today's market since it can support only the
operation system which the IO system supports.
Thus, what is required is an input/output system for a computer which is
easily extendible, which embodies software which is easy to reuse, and
which supports multiple operating systems.
SUMMARY OF THE INVENTION
The present invention is directed to an object-oriented booting framework
for initializing first a degradated file sharing mechanism with fully
defined objects for use in enabling more sophisticated aspects of the
operating system. An object-oriented framework is disclosed for use in
booting a processor with a storage and attached peripherals. The framework
utilizes object-oriented techniques for initializing a computer system by
resetting the storage and one or more peripherals. Then, the framework
initializes a degredated object-oriented environment for use in activating
an operating system personality. The degredated operating envronment
enables file sharing and other basic tasks of importance in loading in the
IO devices, system preferences, and hardware configurations and replaces
itself with the IO file system frameworks for use by the operpating
system.
Further features and advantages of the present invention, as well as the
structure and operation of various embodiments of the present invention,
are described in detail below with reference to the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates input/output service frameworks according to a preferred
embodiment of a preferred embodiment;
FIG. 2 illustrates an overall structural block diagram of the input/output
system of a preferred embodiment;
FIG. 3 illustrates abstractions involving a device access manager and an
interrupt handler, and depicts the data flow between these elements of a
preferred embodiment;
FIG. 4 illustrates an example hardware hierarchy in accordance with a
preferred embodiment;
FIG. 5 is a software hierarchy corresponding to the hardware hierarchy of
FIG. 4 in accordance with a preferred embodiment;
FIG. 6 illustrates a parent/child relationship in accordance with a
preferred embodiment;
FIG. 7 is a block diagram of an example SCSI bus configuration in
accordance with a preferred embodiment;
FIG. 8 illustrates another example hardware hierarchy used for illustrating
the features of a preferred embodiment;
FIG. 9 illustrates a software hierarchy corresponding to the hardware
hierarchy of FIG. 8 in accordance with a preferred embodiment;
FIG. 10 is a block diagram of a computer platform on which the IO system of
a preferred embodiment operates;
FIG. 11 is a block diagram of the components of the booting framework in
accordance with a preferred embodiment;
FIG. 12 is a flowchart illustrating the flow of control in a boot
operation;
FIG. 13 shows a timeline for boot framework processing in accordance with a
preferred embodiment;
FIG. 14 is a block diagram of boot processing in accordance with a
preferred embodiment;
FIG. 15 is a block diagram illustrating the BootImage table of contents in
accordance with a preferred embodiment; and
FIG. 16 recaps, via a booting timeline, the processing utilized in a
preferred embodiment for booting.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Overview
A preferred embodiment is directed to an input/output (IO) system for a
computer. The IO system of a preferred embodiment is easily extendible,
embodies software which is easy to reuse, and supports multiple operating
systems. Other advantages of a preferred embodiment are discussed below.
Object technology is used to implement the IO system of a preferred
embodiment. Thus, the a preferred embodiment represents an object-oriented
IO system. The use of object technology is pervasive and supports
abstractions for many low-level services such as interrupt processing
which to date have been processor-specific and procedural in nature. These
generalized object based abstractions, together with the use of
micro-kernel technology, enable the generation of a new model for device
interfacing.
The IO system of a preferred embodiment is an association of service
providers and their clients. In order to provide a meaningful service to
its clients, the IO system becomes a client of several other service
providers.
FIG. 10 illustrates a block diagram of a computer platform 1002 in which
the object-oriented IO system in accordance with a preferred embodiment.
It should be noted that a preferred embodiment alternatively encompasses
the IO system in combination with the computer platform 1002.
The computer platform 1002 includes hardware components 1003, such as a
random access memory (RAM) 1008 and a central processing unit (CPU) 1006.
It should be noted that the CPU 1006 may represent a single processor, but
preferably represents multiple processors operating in parallel.
The computer platform 1002 also includes peripheral devices which are
connected to the hardware components 1003. These peripheral devices
include an input device or devices (such as a keyboard, a mouse, a light
pen, etc.) 1018, a data storage device 1020 (such as a hard disk or floppy
disk), a display 1024, a printer 1026, and a network adapter 1022. The
computer platform 1002 could be connected to other peripheral devices.
The computer platform 1002 also includes an operating system 1014, and may
include microinstruction code 1010 (also called firmware). The operating
system 1014 may represent a substantially full-function operating system,
such as the Disk Operating System (DOS) and the UNIX operating system.
However, the operating system 1014 may represent other types of operating
systems. Preferably, the operating system 1014 represents a limited
functionality operating system, such as the Mach micro-kernel developed by
IBM, which is well-known to those skilled in the relevant art. Full
featured operating systems may operate as application programs 1030 on the
computer platform 1002.
In a preferred embodiment, the computer platform 1002 is an International
Business Machines (IBM) computer or an IBM-compatible computer. In an
alternative embodiment, the computer platform 1002 is an Apple computer.
One or more application programs 1030 operate in parallel on the computer
platform 1002. Also, one or more device ensembles 1032 operate on the
computer platform 1002.
The device ensembles 1032 collectively represent the object-oriented IO
system of a preferred embodiment. The device ensembles 1032 operate with
each other to provide IO services to end users (such as the applications
1030). The device ensembles 1032 are discussed in greater detail below.
As discussed above, the applications 1030 may represent operating systems,
such as IBM OS/2. Since these applications 1030 are clients of the device
ensembles, the IO system of a preferred embodiment supports a plurality of
operating systems.
The elements of the computer platform 1002 could be depicted in FIG. 10 in
other ways. For example, the device ensembles 1032 could be illustrated as
being part of the operating system 1014 (such that the device ensembles
1032 and the operating system 1014 would occupy the same layer in the
computer platform 1002).
OVERVIEW OF SELECTED OBJECT-ORIENTED TECHNOLOGY CONCEPTS
Object-orient technology and computer programming techniques are generally
well known and described in many publicly available documents, such as
Object-Oriented Design by Grady Booch (Benjamin Cummings 1991) and
Object-Oriented Requirements Analysis and Logical Design by Donald
Firesmith (Wiley 1993). Selected features of object-oriented technology
pertinent to the present invention are discussed in this section.
Objects
Two views of object programming have flowed into the object-oriented (OO)
industry mainstream: self-supporting stand-alone objects and collaborative
lightweight objects. These views are discussed below.
One view of object technology migrates toward the philosophy of
"heavy-weight" objects. This object design tends to encapsulate as much as
possible into a single, stand-alone entity. An example might be a data
base object which encapsulates all the subtleties of a disk-based
relational filing system in a single object. Such an object would embody
and implement the abstractions of field, tuple, table, relation, index and
perhaps query.
This approach yields objects with a large granularity and limits the
flexibility of the embodied abstractions. To refine or adapt the field
abstraction could very well require intimate knowledge of the data base
object's internal structure.
In contrast, the light-weight view of objects tends to limit the scope of
individual objects to functionally and semantically consistent puzzle
pieces designed to collaborate with (perhaps many) other objects in order
to achieve a goal. These are often highly flexible objects which are used
(and reused) on a greater scale.
In this view of objects a simple data base might be a collaborative set of
field objects associated by tuple objects which are in turn contained by
table objects. An index, relation, or query would be separate entities,
collaborating approximately with field, tuple, and table. Each of these
abstractions is able to provide a consistent interface and each may be
easily subclassed to adopt new behaviors.
In a gross simplification, one could draw the analogy between software
libraries and individual subroutines when looking at these two different
approaches to objects. Both provide some self contained unit of
encapsulation and reuse. A preferred embodiment utilizes light-weight,
fine granularity, collaborative objects extensively.
Frameworks
To provide necessary structure to the various subsystems, the lightweight
objects are woven into the fabric of a design framework in which the
public interfaces and inter-relationships are well defined. If objects are
the unit of code reuse, frameworks are the unit of design reuse.
Frameworks are generally well known. Frameworks can span entire class
hierarchies, simultaneously providing the enveloping architecture and
expressing the systematic organization of the design. Frameworks may
decompose into sub-frameworks or several frameworks may be encompassed by
a larger framework.
If the framework is the embodiment of design, then there must be a term to
call the set of objects which implement a framework. For example, in C++
classes and objects are often spoken of separately, distinguishing between
the two by saying a class is the specification and an object is an
instance of the class. According to a preferred embodiment, an
implementation "instance" of a framework is called an ensemble. This term
"ensemble" indicates those classes which collectively implement a
framework. For example, the product which in the past has been called a
"device driver" becomes a Device Ensemble.
Frameworks allow commonalty to be managed through collaboration and
inheritance between the various pieces of an ensemble. Through the use of
well defined class hierarchies, commonalty is pursued and distilled only
where it makes sense in the overall design. Each framework may present its
clients with an appropriate and desirable interface instead of being
confined to a "one-size-fits-all" paradigm enforced across all frameworks.
Features and Advantages of a preferred embodiment
Some features and advantages of the object-oriented IO system of a
preferred embodiment were discussed above. Additional features and
advantages are discussed in the following sections.
Enabling A Developer
The extensive use of objects and frameworks is new to the field of hardware
device interface software and serves to assist the ensemble author in a
number of ways. First, the framework serves to guide the author through
the design issues of orderly start-up, receiving interrupt notification,
servicing device hardware, and orderly shutdown. Second, reuse of ensemble
objects with similar characteristics and purposes allows the author to
concentrate on only those behaviors which are necessarily different.
For example, the author of an ensemble for a new disk controller card may
be able to derive from an existing ensemble, over-riding only those
functions which do actual hardware access. In contrast to this, the author
of an ensemble for an entirely new piece of hardware may not have the
luxury of an ensemble on the shelf to derive from. In this case, many of
the low-level IO frameworks defined by a preferred embodiment will assist
the effort by providing design and architectural guidance to the author.
Encouraging hardware and software innovation
Conventional hardware and software innovation often suffer from mutual
knowledge which is too intimate. Because operating system and application
software "know too much" about the underlying hardware platform, they
exploit this knowledge for maximum value. Use of this information locks
hardware vendors into a mode where change is very hard to accomplish
without breaking applications. Additionally, this knowledge makes it
difficult for software to escape the least common denominator syndrome.
Using object abstractions throughout low level subsystems allows this
deadlock to be resolved. Framework interfaces serve not only to hide the
hardware details from the application, they also hide the application
details from the hardware. This well defined interface between
hardware-dependent and hardware-independent parts of the overall system
encourages both hardware and software innovation, since the hardware as
well as the object based software can change without effects rippling
throughout the entire system.
Location independent device abstractions
By implementing a logical software hierarchy, providing a common
abstraction, and utilizing a shared library system, the IO architecture
allows the same device ensemble to be used regardless of the physical
location or number of occurrences of the hardware. This is to say that an
ensemble for a specific UART chip could service both a port on the
motherboard planar and a port on a third party expansion card without
additional work on the ensemble author's part.
Let resources find you
Another fundamental problem with existing systems is the perspective of the
configuration data base(s) involved. The current top-down resource hunting
perspective necessitates informing the system explicitly about devices
installed or places to look. In some cases, these data bases are used as
input to statistically link drivers into the kernel. In some cases, these
data bases are used as input to statistically link drivers into the
kernel. Configuration files are scattered throughout the system and
multiply as new system services are brought on-line. The result is fairly
uniform; a plethora of obscure, ill- formed, and usually inconsistent set
of steps is required to add a new device.
A better paradigm is one which inverts the current perspective to add a new
device. According to a preferred embodiment, this philosophy is called
"let resources find you." In the "let resources find you" paradigm a SCSI
ensemble would report drives to the mass storage sub-system which would
then report mountable logical drives (volumes or partitions) to the file
system. In this way the user no longer has responsibility for configuring
some database to tell the file system what volumes to mount and the file
system is relieved of the burden of probing all possible hard drive
interfaces for drives and volumes.
A device may not always have as direct and intuitive a client as in the
above example. In these cases a device would register with a central
"parts bin" as a non-specific resource. For example, an RS232C port might
register itself with the parts bin, later to be pulled from the bin by
some user action and used to configure a modem or printer port. In this
case, the user is assured that the options presented are valid because
only those devices which are available and un-assigned find their way to
the parts bin.
"Plug & Play" user model
The culmination of "let resources find you" is the Plug & Play user model.
Plug & Play operation frees the user from having to deal with
configuration files to add or remove input/output hardware.
Dynamic installation and configuration
The dynamic configuration of both hardware and software is a required
feature to support Plug & Play model of a preferred embodiment. To achieve
this goal, configuration of device software requires the dynamic
installation of device specific software (interface ensembles). For
example, a SCSI interface capable of "host-plugging" would need to
reconfigure the devices and services it provides as devices are added or
removed from the bus.
This capability can be extended into more dynamic scenarios where
individual instances of ensemble pieces may be created and destroyed at
will, including un-injection or removal of interrupt handling kernel code
in an unobtrusive manner.
Flexible abstractions with decentralized policy
Use of flexible abstractions throughout the IO architecture allows many
design decisions to be deferred to the framework developer instead of
becoming fixed in the base architecture. This increases the options
available to the designer and allows him to make the best set of
trade-offs with respect to his problem domain. The set of trade-offs can
span performance, security, device allocation, and device access policy
issues.
As an example of the flexibility this provides, each device abstraction
will define whether the device can be shared or is limited to one client
at a time. Decentralization of this device allocation policy decision
allows such policy to change at a later time without having any impact
beyond the scope of the particular device.
In addition to defining client/device access policy, the device abstraction
must allocate required resources such as IO address space and interrupt
source (IRQ). These lower level resources are managed for each IO
framework by an interrupt services framework. The coordination of these
resources is effectively invisible to the individual IO frameworks unless
a conflict occurs.
The effect of decentralized policy is to reduce the number of dependencies
a device abstraction needs to deal with and increase the opportunity for
the individual framework designer to set proper policies at an appropriate
level. The value of decentralized policy becomes more apparent when
porting the software to accommodate new hardware systems which diverge
from the initial implementation's frame of reference.
Increased system reliability
Current levels of systems reliability achieved by today's common desktop
operating system technology are unacceptable for a new system. Progress
has been evident in this area with features like protected address spaces
and user mode drivers. Even with these advances, IO architectures have not
made any significant contribution to the cause of system stability. A
preferred embodiment addresses this shortcoming.
Recovery from processor exceptions within interrupt handlers
Most systems are very unforgiving toward exceptions generated while the
system is executing interrupt code. The resulting system crash is hardly a
model of system reliability and often seems inexplicable. To improve this,
the IO architecture of a preferred embodiment supports both default and
custom exception handlers for the interrupt domain.
Error Logging
IO Error logging is an effective way to track problems and provide
diagnostic feedback when non-fatal errors occur. A preferred embodiment
supports flexible services for such logging.
Automatic reclamation of resources
A preferred embodiment achieves proper reclamation of resources. In
particular, a preferred embodiment detects, and cleans up after, an
abnormal termination.
Support for diverse hardware
A preferred embodiment supports a wide range of devices, processors and
buses. The actively supported devices range from simplistic non-interrupt
driven devices (for example, the Apple SWIM floppy controller chip) to DMA
or channel based disk controllers. A full range of IO buses are supported,
once again from the simple (ISA) to the sophisticated (Micro Channel or
NuBus). This IO architecture is processor-independent and supports all
known processor configurations, including multi-processing.
STRUCTURE OF THE OBJECT-ORIENTED INPUT/OUTPUT SYSTEM
Service Frameworks
When an end user orders a piece of equipment he is seldom simply acquiring
hardware. Rather, he is instead attempting to obtain some level of
service. For example, modem manufacturers provide a means of achieving
some level of telecommunication service. Selling modems is just one
element of the real transaction.
Accordingly, it is no longer adequate to simply make a device accessible,
the focus must shift to the desired services. To this end the IO system of
a preferred embodiment is service oriented. Rather than providing Disk
Drivers, the system provides Mass Storage Services. The traditional
concept of a disk driver is simply a means for software to access a drive.
Mass storage services include additional responsibilities such as
providing the file system with usable partitions and making provisions for
the technical and user interface tasks of drive partitioning and
formatting. It is important to recognize that a preferred embodiment
expands on the traditional roles of device interfaces by raising the level
of service provided.
Some of the input/output services provided by the IO system of a preferred
embodiment include (a) Mass Storage IO services; (b) Keyboard processing
services; (c) Mouse/Pointing device processing services; (d) SCSI
services; (e) Serial communications port services; (f) Expansion bus
management services; (g) Desktop bus IO services; and (h) Power management
services.
According to a preferred embodiment, IO service frameworks are provided for
enabling an end user (such as a human operator, an operating system
function, an application program, etc.) to perform these and other
input/output services. In particular, an end user can interact with these
IO service frameworks to perform any supported input/output operations.
The major IO service frameworks 102, along with some of the specific
services they provide and devices they access, are shown in FIG. 1.
(services and devices are shown as ovals). These IO service frameworks 102
include (1) a mouse/pointing device framework 102A, which provides
services relating to a mouse port, a desktop bus, and a serial mouse; (2)
a desktop bus framework 102B, which provides services relating to an
access bus; (3) a serial port framework 102C, which provides services
relating to the synchronous and asynchronous transfer of data via serial
ports; (4) a power management framework 102D, which provides S services
relating to power sensing and screen management; (5) a parallel port
framework 102E, which provides services relating to interaction with
parallel-type devices (such as printers, portable disks, network
interfaces, etc.); (6) an expansion bus management framework 102F, which
provides services relating to the interaction with expansion buses; (7) a
mass storage device framework, which provides services relating to mass
storage devices; (8) a keyboard framework 102H, which provides services
relating to keyboard input devices; and (9) a | | |
