0U
`
`S005640562A
`[11] Patent Number:
`[45] Date of Patent:
`
`5,640,562
`Jun. 17, 1997
`
`5,504,904
`
`4/1996 Dayan etal. ......c.ccsssssssseseeeee 395/700
`
`Primary Examiner—Kevin A. Kriess
`Assistant Examiner—John Q. Chavis
`Attorney, Agent, or Firm—Timothy J. Crean
`[57]
`ABSTRACT
`
`An embodiment of the present invention provides an effi-
`cient and robust way to incorporate new installation scripts
`into an existing operating system in order to install and
`reboot a system using a new platform specific kernel and
`new device specific drivers. The embodiment determines the
`platform architecture of the system and stores it in an
`address space of an existing operating system kernel. The
`embodiment also pre-processes a file with dynamic entries
`in order to generate device independent package names. If
`the platform architecture type stored in each package
`matches the platform architecture type stored in the kernel
`address space then the file system is used to install thefiles
`from the package onto the system. The existing operating
`system then reboots the system using the installed platform
`specific kernel.
`
`16 Claims, 9 Drawing Sheets
`
`United States Patent
`Wold et al.
`
`115
`
`54]
`
`[75]
`
`[73]
`
`[21]
`
`[22]
`
`(51)
`[52]
`58]
`
`[56]
`
`LAYERING HARDWARE SUPPORT CODE
`ON TOP OF AN EXISTING OPERATING
`SYSTEM
`
`Inventors: Saul G. Wold, Los Gatos; Gary L.
`Owens, Mountain View, both of Calif.
`
`Assignee: Sun Microsystems, Inc., Mountain
`View, Calif.
`
`Appl. No.: 394,859
`
`Feb. 27, 1995
`
`Tint, C15 ecccccssssssssssssecasevasesesssscenssessscssesese GOGE 13/00
`US. Che cvessssssssessessescsscesssssscsssssesnnsnsvanersssssesseoces 395/652
`Field Of Searehe esscssscsssccssssssssssssssscsssssssesseees 395/700
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`...ssesecsecsessessers 395/700
`6/1994 Crosswy et al.
`5,325,532
`7/1995 Rimmeretal. ...
`-
`5,430,845
`
`5,459,867 10/1995 Adams et al.
`
`PARSE_
`DYNAMIC_
`CLUSTERTOC
`
`PLATFORM ARCHITECTURE
`
`
`
`
`
`REBOOT FROM
`
`PLATFORM SPECIFIC
`
`KERNEL
`
`RETRIEVE
`CORREPONDING
`PLATFORM
`ARCHITECTURE FROM
`TABLE
`
`SET “MACHINE TYPE” FIELD
`IN KERNELDATA
`STRUCTURE TO RETRIEVED
`
`Google Exhibit 1046
`Google v. VirtaMove
`
`Google Exhibit 1046
`Google v. VirtaMove
`
`

`

`U.S. Patent
`
`Jun. 17, 1997
`
`Sheet 1 of 9
`
`5,640,562
`
`OO!
`
`FOVHOLS
`
`
`
`7aNUS»OldioadsS
`
`
`
`yoo78504+008SOVSHSLNI|<————_>ONISSIO0ud
`
`b“Sid
`
`61sei6zt
`Zz—_eb]
`
`ZELAYOWSWSS300VWOGNVHY
`
`
`
`SzlLeL
`
`WHOILV1dMINW3LSASF114
`DOLNBISMmO”G09SGOWY3SNWILSASONILVHAdO
`
`OINVNATDOLYSLSNIOTIVISNIZKI
`
`$9ONILSIXSOIWYNAG3SHVdNOILWTIVLSNI
`
`
`601L401SOL601
`
`
`
`ININVAY3dSAIWGWOYddSDIARGLNdNiAW1dSIGOACIA
`sonaa
`OIA
`
`
`
`izie2lwoud
`
`bbb
`
`
`

`

`U.S. Patent
`
`Jun. 17, 1997
`
`Sheet 2 of 9
`
`5,640,562
`
`YES
`
`POWERON ?
`
`203
`
`205
`
`POST
`
`BOOT
`BLOCK
`
`NORMAL
`
`PROCESSING
` YES
`
`OR
`POWER-DOWN
`?
`
`FIG. 2
`
`

`

`U.S. Patent
`
`Jun. 17, 1997
`
`Sheet 3 of 9
`
`5,640,562
`
`
` BOOT
`
`BLOCK
`
`LOAD EXISTING
`KERNEL
`
`
`
`
`
`303
`
`EXISTING
`KERNEL
`
`FIG. 3
`
`

`

`US. Patent
`
`Jun. 17, 1997
`
`Sheet 4 of 9
`
`5,640,562
`
`KERNEL
`
`REBOOT FROM
`PLATFORM SPECIFIC
`
`LY2INSTALL
`
`PARSE_
`DYNAMIC
`CLUSTERTOC
`
`INSTALLATION
`
`FIG. 4
`
`

`

`US. Patent
`
`Jun. 17, 1997
`
`Sheet 5 of 9
`
`5,640,562
`
`FIG. 5
`
`YES
`
`501
`
`RETRIEVE
`
`PLATFORM NAME
`
`FROM PROM
`
`PLATFORM TABLE
`
`NO
`
` RETRIEVE
`CORREPONDING
`PLATFORM
`ARCHITECTURE FROM
`TABLE
`
`
`
`
`
`PLATFORM ARCHITECTURE
`
`SET “MACHINE TYPE” FIELD
`IN KERNEL DATA
`STRUCTURE TO RETRIEVED
`
`

`

`US. Patent
`
`Jun. 17, 1997
`
`Sheet 6 of 9
`
`5,640,562
`
`
`
`RETRIEVE
`
`‘CLUSTERTOC-DYNAMIC
`
`
`ENTRIES
`REMAIN?
`
`
` RETRIEVE NEXT
`
`UNPROCESSED
`
`ENTRY FROM
`FILE
`
` 601
`
`
`
`
`IN
`
`"NEW_PARAMETER(<TEST><ARG)<PARAMETER>"
`FORMAT?
`
`
`
`
`WRITE ENTRY
`‘AS IS” TO
`CLUSTERTOC
`
`
`PARSE "PARAMETER"
`INFORMATION FROM
`
`ENTRY INTO
`
`STANDARD
`FORMAT, WRITE
`
`PARSE OUTPUT TO
`CLUSTERTOC FILE
`
`
`FIG. 6
`
`

`

`US. Patent
`
`Jun. 17, 1997
`
`Sheet 7 of 9
`
`5,640,562
`
`METACLUSTER = VALUE
`CLUSTER = VALUE
`PACKAGE= VALUE
`
`PACKAGE = VALUE
`END
`
`END
`
`CLUSTER = VALUE
`
`END
`
`END
`
`METACLUSTER = VALUE
`
`END
`
`FIG. 7
`
`

`

`U.S. Patent
`
`Jun. 17, 1997
`
`Sheet 8 of 9
`
`5,640,562
`
`NEW_PARAMETER = (<TEST><ARGUMENT>)<PARAMETER>
`
`FIG. 8
`
`

`

`US. Patent
`
`Jun. 17, 1997
`
`Sheet 9 of 9
`
`5,640,562
`
`
`RETRIEVE
`-CLUSTERTOC
`
`
`FILE
`
`
`
`
`PROMPT USER
`WITH METACLUSTER,
`
`
`CLUSTER, AND
`
`
`PACKAGE OPTIONS
`
`
`
`
`904
`
`903
`
`905
`
`907
`
`
`
`
`
`
`RECEIVE USER
`SELECTIONS AND
`STORE RESULTS AS
`
`A LIST OF PACKAGES
`
`
`
`
`
`QUERY KERNEL
`FOR
`PLATFORM
`
`ARCHITECTURE
`
`
` BO
`
`UNPROCESSED
`PACKAGES
`
`REMAIN?
`
`
`
`
`RETRIEVE NEXT
`UNPROCESSED
`
`PACKAGE
`
`
`
`
`RETRIEVE
`
`"ARCHITECTURE"
`STRING FROM
`
`RETRIEVED PACKAGE
` 917
`
`INSTALL FILES
`FROM PACKAGE
`
`

`

`5,640,562
`
`1
`LAYERING HARDWARE SUPPORT CODE
`ON TOP OF AN EXISTING OPERATING
`SYSTEM
`
`BACKGROUND OF THE INVENTION
`
`5
`
`2
`Since the resources of any given operating system developer
`are notlimitless, they cannot develop kernels to support each
`and every platform on the market. They also cannot develop
`installation code to install all possible device drivers.
`Therefore, any given version (called a “base version”) of an
`operating system only includesinstallation code to install a
`limited number of kernels and drivers.
`
`1. Field of the Invention
`The present invention relates to the field of operating
`A problem arises when original equipment manufacturers
`systems, and, more specifically, to incorporating into an
`(“OEMs”) develop new computer systems which are not
`existing operating system, installation codeto install previ-
`supported by the base version of the operating system. A
`ously unsupported platform specific kernels and device
`user of the new computer system, running the base version
`specific drivers.
`of the operating system, will not be able to access unsup-
`2. Background of the Invention
`ported hardware components because the operating system
`Whena user flips a computer’s ON switch the computer
`never installs a platform specific kernel and device specific
`begins a process knownas the system boot. The system boot
`drivers which can recognize and handle application program
`process on most machines consists of the following basic
`calls to the new hardware. Being unable to communicate
`steps. First the system firmware in the programmable read-
`with some of the components of your system can cause
`only memory (“PROM”) runs a power-on self-test
`serious problems. For example,if the unsupported hardware
`(“POST”) to ensure that all hardware components are func-
`componentis the user’s current keyboard then the user will
`tioning properly. If the POST test completes successfully
`be unable to enter data into the system.
`then a boot block is read from a permanent memory area
`In the past, operating system developers and OEMshave
`(e.g., a disk drive) on the computer. When bootingto install
`tried to solve this problem in a number of different ways. For
`a new system, the boot block typically instructs the com-
`example, some operating system developers transfer to each
`puter to search a CD-ROM drive or a disk drive for an
`OEMacopy of the source code for the base version of the
`25
`operating system kernel. The operating system kernelis the
`operating system. The OEM then modifies the source code
`core of the operating system. The kernel contains the most
`to create a new kernel with some new device drivers which
`essential operating system services, such as task schedulers
`together accept requests from application programs and
`and interrupt handlers. When the operating system kernel
`translate those requests into a language which the
`files are found they are read into the computer’s random
`(previously) unsupported hardware component can under-
`access memory (“RAM”) and control is transferred to the
`stand. The OEM then transfers the modified operating
`kernel. The operating system then takes on the more com-
`system onto a compactdisc and offers the new CD forsale.
`plicated tasks that the boot block code cannot manage. For
`Oneof the problems with this approachis that a user of the
`example, the operating system mounts the necessary file-
`operating system needs to purchase separate CDs from
`systems and loads input/output (“I/O”) routines. One of the
`separate sources in order to have copies of the operating
`masonsfor loading the operating system from a CD-ROM
`system which execute on the different hardware systems
`drive or disk drive and not pre-installing the operating
`available in the market.
`system is to allow users a choice of which operating system
`to load and use.
`
`30
`
`35
`
`One of the more important functions that the operating
`system kernel performs during system bootis installation of
`device specific drivers. A driver is a program that serves as
`an interface between two programs or between a program
`and a hardware component. For example, to ensure that a
`network interface card will work with a particular network
`software package, drivers are used. To install means to set up
`and prepare for operation. Therefore, to install device driv-
`ers means to set up and prepare the device drivers to work
`with the computer and its device. Installing device specific
`drivers to operate the hardware components of a computer
`has been customary since the advent of personal computers
`and workstations. Device specific drivers are not typically
`pre-installed because computers are general purpose
`machines designed and developed to work with a myriad of
`different hardware components to accomplish thousands of
`different functions. Dueto limitations in memory capacity it
`is impractical to load each and every device driver that could
`possibly be invoked by the system. Instead, the computer
`determines which hardware components are actually con-
`nected to the system, often through a “dialog” with a
`systems administrator, and then loads the device drivers for
`those hardware components.
`Typically, the responsibility to develop device specific
`drivers falls to the manufacturer of the device. Responsibil-
`ity to develop platform specific kernels fails primarily to
`operating system developers. Finally, responsibility to
`develop code to install device specific drivers and. platform
`specific kernels falls to developers of operating systems.
`
`40
`
`45
`
`55
`
`65
`
`In addition to having the problem of separate CDs,a user,
`whois not generally interested in the procedural and admin-
`istrative details of installing additional kernels, must none-
`theless struggle with the various installation procedures
`from different OEMs. Thus a need exists to supply a
`consistent installation procedure across various kernels.
`
`SUMMARYOF THE INVENTION
`
`A preferred embodiment of the present invention incor-
`porates new installation scripts into the installation process
`of an existing operating system in order to install new
`computer specific kernels and device specific drivers on a
`new computer. To begin the process the preferred embodi-
`ment boots the new computer using an existing operating
`system kernel. The existing operating system kernel deter-
`mines a computer architecture type of the new computer and
`stores the architecture type in a kernel address space. Then
`the existing operating system kernel inserts into a firstfile,
`references to files comprising the new computer specific
`kernel, as well as information regarding a computer archi-
`tecture type on which to install the new computer specific
`kernel. Next, the existing operating system kernel retrieves
`the computer architecture type from thefirst file and com-
`pares the retrieved computer architecture type with the
`determined computer architecture type. When the computer
`architecture types match,
`the existing operating system
`kernel installs the files comprising the new computer spe-
`cific kernel. In response to the installation, the existing
`operating system kernel reboots the new computer from the
`new computer specific kernel.
`
`

`

`3
`DESCRIPTION OF THE DRAWINGS
`
`5,640,562
`
`4
`controlling the allocation and usage of the hardware
`resources of the system, such as memory 113, processing
`The objects, features and advantages of the system of the
`unit 111, and CD-ROM drive 107. The preferred operating
`present
`invention will be apparent from the following
`system is the Solaris® operating system from Sun
`description in which:
`Microsystems, Inc.® of Mountain View,Calif. (Solaris, Sun,
`FIG. 1 is a block diagram of a computer system for
`and Sun Microsystems are registered trademarks of Sun
`practicing a preferred embodimentof the present invention.
`Microsystems, Inc.) The remaining components of the RAM
`FIG. 2 is a diagram of the computer system operation
`113 andthe operating system 119 are perhaps best described
`by way of example.
`from the time a user rams the computer “on”to the time the
`The process which leads to execution of the preferred
`user enters a “halt” or “power-down”request.
`embodiment begins when an OEM develops a new platform
`FIG. 3 is a flow diagram of a boot block routine for
`that includes new hardware components that need to be
`initiating a preferred system boot process.
`accessedorinstalled when booting the new platform. As part
`FIG. 4 is a diagram for operation of an existing operating
`of the platform development process the OEM ports an
`system kernel routine which installs an appropriate platform
`existing operating system to the new platform. When the
`specific kernel and device specific drivers and then reboots
`development process is complete the OEM converts the
`the computer with platform specific kernel.
`modified operating system into an agreed upon format,
`FIG. 5 is a flow diagram of a ly2install script which
`stores the package in a named directory on a storage
`provides information that the installation routines uses to
`medium, and delivers it to the operating system developer.
`determine which files to install on the computer system.
`The operating system developer runs the modified oper-
`FIG.6 is a flow diagram of a parse_dynamic_clustertoc
`ating system through its standard testing procedure. If the
`routine which pre-processes a file named “.clustertoc.dy-
`modified operating system passesthe tests then it is incor-
`namic”in order to insert device independent package names
`porated into the existing operating system and a user is
`into a file named “.clustertoc”.
`permitted to install the new package onto the new platform
`FIG.7 illustrates a typical “clustertoc”file.
`25
`using the preferred embodiment of the present invention.
`FIG.8illustrates a preferred format for the “.clustertoc-
`FIGS. 2-6 and 9 are flow diagrams that illustrate an
`dynamicfile.”
`operation of the preferred embodiment on the computer
`FIG. 9 a flow diagram of theinstallation routine which
`system of FIG. 1. In particular, FIG. 2 is a flow diagram of
`installs files onto a system disk.
`the system operation from the time a user turns the computer
`“on” to the time the user enters a “halt” or “power-down”
`DESCRIPTION OF THE PREFERRED
`request. In step 201 the system awaits power. Uponinitiation
`EMBODIMENT
`of power the power-on self-test (“POST”) 121 (FIG. 1) is
`executed in step 203. The POST routine makessure that all
`the hardware components are running andthat the process-
`ing unit 111 and the RAM 113 are functioning properly.
`Upon successful return from the POST routine, the boot
`block 123 (FIG. 1) is executed (step 205). The boot block
`routine loads an existing operating system kernel 125 which
`initiates the preferred installation and reboot process ofthe
`present invention. Once the computer 101 has been rebooted.
`from a new platform specific kernel 127, normal processing
`continues (step 207) until the user enters a system halt or
`power-down request (step 209).
`FIG. 3 is a flow diagram of the boot block 123 for
`initiating the preferred system boot process. The preferred
`boot block routine loads and invokes an existing operating
`system kernel 125 (steps 301 and 303). Upon return from
`executing the existing operating system kernel routine, the
`new platform specific kernel 127 is executing on the pro-
`cessing unit 111. Therefore, while the ultimate goal of the
`preferred embodimentis to reboot the computer 101 with the
`new platform specific kernel 127, an existing operating
`system routine must fast be executed long enoughtoinstall
`and invoke the new platform specific kernel.
`FIG.4 is a flow diagram for the existing operating system
`kernel 125 (FIG. 1) whichinstalls the appropriate platform
`specific kernel and device specific drivers and then reboots
`the computer with the platform specific kernel. For purposes
`ofclarity, FIG. 4 only contains those steps preferably taken
`to perform a new system installation. Those of ordinary skill
`will understand that existing operating system kernels per-
`form a number of tasks in addition to those illustrated in
`FIG. 4. For example, the existing operating system kernel
`127 may also be capable of performing a system bootfrom
`disk. In that case the existing kernel accesses files previously
`installed on the disk (during a new system installation boot)
`and boots the system from thosefiles.
`
`The preferred embodiment of the present invention pro-
`vides a method and system for incorporating new installa-
`tion scripts into an existing operating system in order to
`install new platform specific kernels and device specific
`drivers onto a new platform. The preferred embodiment
`addresses the situation where an OEM develops new plat-
`form specific kernels and device specific drivers to support
`a previously unsupported platform. For example, when an
`OEM develops a new platform it may contain a new
`keyboard and a new disk drive. Therefore, the OEM devel-
`ops a new keyboard driver, a new disk driver, and modifies
`the existing operating system kernel to use the new drivers.
`The new drivers and the modified operating system are
`together known as a new “package.” The preferred embodi-
`ment ofthe present invention, in conjunction with an exist-
`ing installation program, executes the new installation
`scripts to install the new package onto the new platform.
`Onceinstalled the new platform can be rebooted from the
`new platform specific kernel.
`FIG. 1 is a block diagram of a computer system 100 for
`practicing the preferred embodiment of the present inven-
`tion. The computer system 100 includes a computer 101, a
`video display device 103, an input device 105, such as a
`keyboard, mouse, or pointing device, a CD-ROMdrive 107,
`and a permanent storage device 109, such as a disk drive.
`The computer 101 includes a processing unit 111, a
`random access memory (“RAM”) 113, a programmable
`read-only memory (“PROM”) 115,and an interface 117 for
`enabling communication between the processing unit 111
`and the RAM 113 or the PROM I15. Theinterface 117 also
`facilitates communication between the processing unit 111
`and peripheral devices (e.g., the video display device 103,
`the input device 105, and the CD-ROM drive 107).
`The computer memory 113 holds a number of items,
`including an operating system 119 that is responsible for
`
`10
`
`15
`
`20
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`

`

`5,640,562
`
`20
`
`25
`
`30
`
`35
`
`6
`“.clustertoc”file 132. Therefore, the differences between the
`two files (i.c.,
`the preferred additions provided by the
`developers of the present invention) will be more easily
`recognized once the existing format of the “.clustertoc”file
`132 is understood.
`FIG. 7 illustrates a typical “.clustertoc” file 132. The
`“clustertoc” file 132 is preferably an ASCTI file that
`describes a hierarchical view of a software product. The
`“clustertoc” file 132 preferably resides in the top-level
`directory containing the product.
`The hierarchy described by the “.clustertoc”file 132 can
`be of arbitrary depth, although the preferred installation
`routine 131 assumesthatit has three levels. The hierarchyis
`described herein in a bottom-up manner. The “lowest”level
`in the hierarchy is a “package” which can be thoughtof as
`a grouping of logically related files. The next level in the
`hierarchy is the “cluster” which collects packages into
`functional units. The highest level is the “meta-cluster”
`which collects packages and clusters together into typical
`configurations. A typical cluster may include packages pro-
`vided by an OEM of the computer. A typical meta-cluster
`may include the minimum packages required to boot and
`configure the operating system to the point of running a
`multi-user shell or it may contain the software packages
`most often used by an end-user of the operating system.
`The hierarchy exists to facilitate the selection or deselec-
`tion of software for installation at varying levels of granu-
`larity. Interacting at the package level provides the finest
`level of control over what software is to be installed.
`Interacting at the meta-cluster level provides the coarsest
`level of control.
`
`5
`Steps 401, 403, and 405 work together to install the
`platform specific kernel 127 and the device specific drivers
`129 onto the system 100. The ly2install script 135 is one of
`the new additionsof the present invention. In step 401, the
`Ly2install script determines the platform name of the com-
`puter platform 101 and then mapsthe platform nameto its
`appropriate platform architecture type. The parse_
`dynamic__clustertoc script 137 is another new addition of
`the present
`invention. The parse_dynamic__clustertoc
`script, invoked in step 403, generates a file named “.clus-
`tertoc” 132 which contains device independent package
`names. The installation routine 131, invoked in step 405,
`then usesthe platform architecture information, along with
`the device independent package names, to install the plat-
`form specific kernel 127 and the device specific drivers 129
`onto the system 100. Upon return from the installation
`routine, the new platform specific kernel 127 resides on the
`permanent storage device 109. The existing kernel routine
`125 then reboots the computer 101 using the new platform
`specific kernel 127 (step 409).
`FIG.5 is a flow diagram ofthe ly2install script 135 which
`provides information that the installation routine 131 uses to
`determine which files to install on the system 100. In step
`501 the ly2install script retrieves, preferably from the
`PROM115,the platform name of the computer 101. In the
`preferred embodimentthe platform nameisstored in a root
`node of the PROM 115 by the OEM which developed the
`system 100. Theplatform nameis preferably retrieved using
`the Unix command “prtconf.” The prtconf command
`retrieves system configuration information. The information
`includes the platform name, the total memory space, and the
`AsFIG.7illustrates, each entry in the “.clustertoc” file
`configuration ofthe systemperipherals formatted as a device
`132 is a line that establishes the value of a parameter in the
`tree. In step 503 the ly2install script retrieves a platform
`following form: “parameter=value.” Parameters are grouped
`table 136 from the CD ROM drive 107 so thatthe platform
`by cluster or meta-cluster. The start of a cluster description
`name can be mapped to an appropriate platform architecture
`is defined by a line of the form: “cluster=value.” Likewise,
`type. In the preferred embodiment the operating system
`the start of a meta-cluster description is defined by a line of
`developer maintains the platform table 136. In step 505, the
`the form: “meta-cluster=value.” Each cluster or meta-cluster
`ly2install script determines whether the platform name is
`description is preferably terminated by an “END.”
`stored in the platform table.If it is not stored in the table then
`The installation routine 131 retrieves the meta-cluster,
`the ly2install script ends processing.If the platform name is
`cluster, and package names and presents them on a user
`in the platform table then steps 507 and 509 are performed.
`interface to the systems administrator performing the instal-
`In step 507, the ly2install script retrieves the appropriate
`lation. The systems administrator selects one meta-cluster,
`platform architecture type from the table. In step 509, the
`ly2install script sets the “machine type”field in the existing
`and within that meta-cluster, selects or deselects multiple
`clusters, and/or packages. The installation routine then
`kernel 125 to the retrieved platform architecture type.In the
`installs the selected packages on the system. Previous ver-
`preferred embodimentthe “adb” commandis used to set the
`sions of the installation routine expected the “.clustertoc”
`“machinetype”field in the kernel. Adb is a general purpose
`file 132 to describe four required meta-clusters for the base
`debugger. A debugger like adb is preferred because the
`operating system product. The meta-cluster “SUNWCall”
`ly2install script runs in the user mode address space of the
`containsall of the software packages in the operating system
`operating system while the kernel data structure resides in a
`distribution from the operating system developer. The meta-
`supervisor virtual address space. Routines which run in the
`cluster “SUNWCuser” contains the typical software pack-
`user space are not permitted to modify the kernel, so an
`indirect method of kernel modification is needed. Because
`ages for an end-user of the operating system distribution.
`Finally, the meta-cluster “SUNWCreq” contains the bare-
`adb runs in the same supervisor address space as the kernel,
`minimum packages required to boot and configure the
`it can modify the kernel data structure.
`operating system to the point of running a multi-user shell.
`FIG. 6 is a flow diagram of the parse_dynamic_
`FIG. 8 illustrates a preferred format for the “.clustertoc-
`clustertoc routine 137 which pre-processes a file named
`dynamic” file 139. The “.clustertoc.dynamic” 139 file is
`“clustertoc.dynamic” 139 in order to generate the “‘.cluster-
`toc” file 132. The “.clustertoc” file 132 contains device
`conceptually a superset of the “.clustertoc”file 132 because
`it contains each and every entry that will be found in the
`independent package names. The creation of the “.cluster-
`*“clustertoc”file 132. In addition, the “.clustertoc.dynamic”
`toc.dynamic”file 139 is yet another of the new additions
`file 139 contains a new type of entry of the format “new-
`provided by the present invention. Before discussing either
`the format of the “.clustertoc.dynamic” file 139 or the
`parameter=(<test><test argument>)<parameter>.” The pur-
`pose of the new type of entry is perhaps best described by
`preferred method for pre-processing the “.clustertoc.dy-
`way of example.
`namic”file 139, it will be helpful to understand the format
`of the “.clustertoc”file 132. This is so because the “.clus-
`the “Parse-Dynamic_
`As was discussed above,
`tertoc.dynamic”file 139 is conceptually a superset of the
`Clustertoc” routine pre-processesthe “.clustertoc.dynamic”
`
`40
`
`45
`
`50
`
`55
`
`65
`
`

`

`5,640,562
`
`7
`file 139 and generates the “.clustertoc” file 132. In general,
`the “Parse-Dynamic__Clustertoc” routine reads each entry in
`the “.clustertoc.dynamic”file 139 (steps 601-605) and when
`it encounters an entry of the type “meta-cluster=__—”’ or
`“cluster=
`” or “package=__” it merely writes the
`entry “as is” to the “.clustertoc”file 132 (step 609).
`Whenthe “Parse-Dynamic_Clustertoc” routine encoun-
`ters an entry of the type “new-parameter=(<test><test
`argument>)<parameter>”(step 607) it runs the “test” using
`the “test argument” (step 611) andif the result of the test is
`“True” (step 613) then it parses the “parameter” information
`from the entry into the standard format and writes the parse
`outputto the “.clustertoc” file 132 (step 615). If the result of
`the test is “False” then the “parameter” information from the
`entry is not written to the ““.clustertoc” file 132. For example,
`the preferred embodiment may use a “platform”test with the
`name of the new platform as the test argument.If the result
`of the test comes back “True” then entries for the meta-
`clusters, clusters, and packages of the device specific drivers
`for that platform would be written to the “.clustertoc”file
`132 for later installation.
`
`FIG.9 is a flow diagram of the installation routine 131
`which installs files onto the permanent storage device 109.
`In step 901, the installation routine retrieves the “.clustertoc”
`file 132. In step 903, the installation routine retrieves the
`meta-cluster, cluster, and package names from the “.cluster-
`toc”file 132 and presents them on a user interface to the
`systems administrator performing the installation. Previous
`versions of the installation routine 131 expected the “.clus-
`tertoc” file 132 to describe four required meta-clusters for
`the base operating system product. The meta-cluster “SUN-
`WCall” contains all of the software packages in the oper-
`ating system distribution from the operating system devel-
`oper. The meta-cluster “SUNWCuser” contains the typical
`software packages for an end-user of the operating system
`distribution. The meta-cluster “SUNWCprog” contains the
`typical software packages for a programmer. For example,
`the “SUNWCprog” meta-cluster typically contains header
`files, debuggers, and compilers. Finally, the meta-cluster
`“SUNWCreq” contains the bare-minimum packages
`required to boot and configure the operating system to the
`point of running a multi-user shell. The preferred embodi-
`ment of the present invention provides a fifth meta-cluster
`named “SUNWCXall.” The “SUNWCXall” meta-cluster
`containsall ofthe software packages in the operating system
`distribution from the operating system developer and, in
`addition, it contains all of the new software packages from
`the OEMs. Given these options, the systems administrator
`selects a certain meta-cluster, and within the selected meta-
`cluster, certain clusters, and/or packages. The installation
`routine stores the results as a list of packages (step 905). In
`step 907, the installation routine queries the existing kernel
`125 for the platform architecture of the computer 101. For
`each package (steps 909 and 911), the installation routine
`compares the “architecture” string stored in the package
`(step 913) with the “platform architecture type” retrieved
`from the kernel (step 915). Preferably, all packages are
`stored in a known directory on the CD ROM drive 107.
`Therefore,
`the installation routine accesses the known
`directory, finds the “‘architecture=
`” swing and then
`performs its comparison. If no match occurs then processing
`continues with step 909. If a match does occur then the
`installation routine invokes the file system 133 to install the
`package on the system (step 917).
`Tf all packages have been processed then processing ends
`in the installation routine. Processing continues, however,at
`step 407 (FIG. 4) of the existing kernel routine 125. In step
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`8
`407 the existing kernel routine reboots the system 100 from
`the platform specific kernel 127. Upon completion of the
`teboot, processing ceases in the existing kernel routine.
`Processing continues, however, in the platform specific
`kernel 127 (step 207 of FIG.2) until the user enters a “halt”
`or “power-down” request (step 209).
`The method and system of the preferred embodiment, as
`described above, provides a number of benefits and advan-
`tages. By primarily modifying the underlying state data
`while leaving the existing installation coderelatively intact,
`the preferred embodimentsatisfies the, at times conflicting,
`requirements of OEMs,
`independent software vendors
`(ISVs), and end-users.
`The ISVs do not want the code in the base version of the
`operating system to be disturbed because the ISVs have
`previously expended their own resources to develop appli-
`cation programs which work with the base version of the
`operating system. The ISVs would like to continue to run
`theiz applications on the base version of the operating
`system, and would like to avoid being forced to expend
`additional resources to develop new application code which
`operates on the modified operating system. The operating
`system developer would like to protect the investmentofits
`ISVs sothat in the future the ISVs will continueto port their
`applications to the operating system developer’s operating
`system. By keeping the existing installation code intact the
`needs of the ISVs are met.
`
`Atthe same time the operating system developer would
`like to support the new computer systems of the OEMs
`because such systems increase the potential market for the
`operating system developer’s product. By providing the new
`installation scripts the needs of the OEMsare met.
`Finally, the operating system developer would like to offer
`these different versionsof its operating system on oneset of
`compact disks so that users of the operating system can
`avoid buying a separate CD and learning a new installation
`procedure for each new system developed by an OEM. By
`incorporating the installation scripts into the existing oper-
`ating system, a user can install, from one CD and with one
`installation procedure, the new platform specific kernel or
`any of the previously existing kernels.
`It will be appreciated that, although a specific embodi-
`mentof the present inventi