Patent application title: Method and apparatus for downloading executable code in a non-disruptive manner
Naresh Talati (Voorhees, NJ, US)
Anton Bodner, Jr. (Turnesville, NJ, US)
IPC8 Class: AG06F944FI
Class name: Data processing: software development, installation, and management software upgrading or updating
Publication date: 2009-05-21
Patent application number: 20090133009
Patent application title: Method and apparatus for downloading executable code in a non-disruptive manner
Anton Bodner, JR.
Wong Cabello Lutsch Rutherford & Brucculeri LLP
Origin: HOUSTON, TX US
IPC8 Class: AG06F944FI
A method and apparatus for achieving a non-disruptive code load that
includes assigning an endpoint to a non-disruptive code loading new
process, loading the process into a memory location of a system and
starting the process, wherein a previous process is instructed to forward
all messages on its queue to the new process to where all new signals are
1. An apparatus for non-disruptively replacing code in a system,
comprising:a. a plurality of tasks, each task in the plurality of tasks
having a task identifier;b. a plurality of processes in executable form,
each procedural code module in the plurality of procedural code modules
having a code module identifier;c. a table including mapping entries,
each entry associating a particular task from the plurality of tasks with
a particular procedural code module from the plurality of procedural code
modules by mapping the task identifier of the task to the code module
identifier of the procedural code module, wherein changing the
association for a given task from a first procedural code module to a
second procedural code module includes remapping of the task identifier
of the given task to the code module identifier of the second procedural
code module;d. a signal sent from the first code procedural module to the
second procedural code module, whereby the second procedural code module
receives information relevant to the second procedural code module
assuming task responsibilities from the first procedural code after the
task identifier of the given task has been remapped; ande. a first
process causing a task to be performed by invoking a first procedural
code module associated by the table at a first time with the task, and a
second process causing the task to be performed by invoking a second
procedural code module associated at a later time by the table with the
task, wherein the system remains active between invocation of the first
procedural code module and invocation of the second procedural code
2. The apparatus of claim 1, wherein the signal includes data used to update a database that the second procedural code module accesses after the task identifier of the given task has been remapped.
3. The apparatus of claim 1, wherein the table associates tasks with code modules without intervening association to object-oriented classes or objects.
4. The apparatus of claim 1, further comprising:f. for each task, a request structure, said request structure remaining unchanged when the mapping entry changes from associating a first procedural code module with the task to a second procedural code module.
5. A method for non-disruptively replacing code in a computer system, comprising:a. identifying a set of tasks to be performed, each task having a task identifier;b. within a table, associating, each task identifier with a respective procedural code module in executable form, whereby a particular task is associated with a first procedural code module by a first task identifier;c. obtaining by a first process a reference to the first procedural code module through its association with the first task identifier in the table;d. using the reference to the first procedural code module, invoking the first procedural code module by the first process;e. changing the table so that the first task identifier is associated with a second procedural code module;f. sending a signal from the first procedural code module to a second procedural code module, whereby the second procedural code module receives information relevant to the second procedural code module assuming responsibility from the first procedural for performing the particular task;g. obtaining by a second process, not necessarily distinct from the first process, a reference to the second procedural code module through its association with the first task identifier in the table; andh. using the reference to the first procedural code module, invoking the second procedural code module by the second process, wherein the system remains active between invoking the first procedural code module and invoking the second procedural code module.
6. The method of claim 5, wherein the signal includes data to update a database accessed by the second procedural code module.
7. The method of claim 5, further comprising:i. assigning each task to a respective position in the table; andj. retaining the assignment of each task to its respective position through one or more changes in association of the task with procedural code modules.
8. The method of claim 7, further comprising:k. assigning to each task a request structure, said request structure remaining unchanged when the mapping entry changes from associating a first procedural code module with the task to a second procedural code module.
9. The method of claim 5, wherein association, within the table, of each task with a respective procedural code module is done without intervening association to object-oriented classes or objects.
This application is a continuation of U.S. patent application Ser.
No. 10/252,430, entitled "Method and Apparatus for Downloading Executable
Code in a Non-Disruptive Manner", filed Sep. 24, 2002 now U.S. Pat. No.
FIELD OF THE INVENTION
The present invention relates generally to downloading software code onto a computer hardware device. More particularly, the present invention relates to downloading software code to an active hardware device, which is part of the system, such that the active hardware device is available to the rest of the system all the time, and hence software upgrade does not disrupt the system operation.
BACKGROUND OF THE INVENTION
The field of computer technology advances at almost a lightening pace. Equipment rarely has more than a five-year life. In most instances, the life is only two to three years. In some instances, it is possible to replace various pieces of the equipment. In other instances, all that is required is an upgrade of the firmware or software. The problem arises when other system devices communicating with the system device being upgraded, cannot tolerate even few milliseconds of unavailability of the system device under upgrade. Failure to do so may result in system failure and hence significant down time. Computer equipment owners demand near perfect operation of their equipment. Owners talk in terms of anything less than 99.999% availability as being unacceptable.
Shutting down a computer system can cost a company thousands and thousands of dollars for each hour the system remains unavailable. Upgrades of computer equipment usually result in some downtime of the processing. This has resulted in technology assistants upgrading equipment at odd hours of the morning. This results in additional costs to the company as well.
Software upgrades on larger computer systems are needed to add additional features or fix reoccurring problems or bugs. In light of the financial consequences of shutting down a computer, there is a need to upgrade firmware without disrupting the processing time. Prior systems involve halting the real-time system, while the upgrade in code is performed, which may require halting the complete system due to other system devices requiring immediate response from the system device under upgrade. This is not ideal for the aforementioned reasons. Furthermore, the owner of the equipment is less reluctant to perform upgrades or fix bugs unless absolutely necessary.
Accordingly, it is desirable to provide an apparatus and method that enables the owner of computer systems to upgrade the software of one of their devices to add new features or fix software bugs, in a way so that the device being upgrade is always available to other system devices. This in turn will allow the computer system to run or operate in real time and continue to process requests.
SUMMARY OF THE INVENTION
It is therefore a feature and advantage of the present invention to provide a method and apparatus for downloading a new version of executable software code onto a system without the need to bring the system to a halt.
It is another feature and advantage of the present invention to provide a fast and efficient means of processing time to upgrade a process or thread,
The above and other features and advantages are achieved through the use of a novel endpoint identification tag that is attached to every process, an endpoint process table that permits all processes to communicate with each other, and to enable the new process to eventually replace the previous process as herein disclosed. It is important to note that new process and the previous process it replaces have the same endpoint.
In accordance with one embodiment of the present invention, a method for non-disruptive code loading includes the steps of loading a new process into memory, wherein the new process includes an endpoint (same as the process it is replacing), starting the new process and creating an identifier for the new process.
A further step to this method can include recording of the identifier by a downloader, whereby a control process eventually requests and obtains the new process identifier. The identifier is used to enable the previous process and the new process to communicate to one another. The inclusion of an identifier and an endpoint for the new process results in the building of an endpoint lookup table, which results in the step of looking up the endpoint of the process to enable processes to communicate with each other.
In a further aspect of this embodiment, a previous process sends or transmits update signals to the new process to update its internal database. These signals include the process identification numbers among other information to enable the new process to execute and operate as the previous process. While the update signals are being transmitted, the previous process continues to process and service requests that are received on the queue of the previous process. Once the complete database has been sent, the step of alerting the control process about the completion of transmission of the database is accomplished. Further steps include forwarding any remaining requests to the new process queue, in response to the database being transferred, and processing update signals received by the new process queue. When the new process begins to execute and process all the requests for the system, the previous process can be deleted or removed to help alleviate any memory problems that might occur.
In another aspect of this invention, the update signals transferred between the new and previous process remain approximately the same between code revisions.
In an alternate embodiment of the present invention, an apparatus for loading code non-disruptively includes means for loading a new process into memory, wherein the new process comprises an endpoint, means for starting the new process and means creating an identifier for the new process. This alternate embodiment can further include means for recording the identifier by means for downloading and means for obtaining the identifier for a control process.
In another aspect of this alternate embodiment, additional elements are means for instructing a previous process to perform a non-disruptive switchover to the new process, which is accomplished by a control process. At the instruction to perform a non-disruptive switchover, means for transmitting communicates the identifier to the new process. After some further communication between the new and previous process, means for notifying instructs the control process that the database has been transferred to the new process. Once the endpoint lookup table is updated by replacing the endpoint entry, containing the identification number of the previous process with the identifier of the new process, all communication from other processes are directed to the new process. This is transparent to the other processes, since they send the message to the same end point.
Once the new process is activated, the previous process instructs means for forwarding to transmit any remaining messages to a queue of the new process, where the new process begins to process requests.
In a further embodiment of this invention, an apparatus for loading code non-disruptively includes an operating system that generates an identifier for a new process, wherein the new process includes an endpoint, a memory device linked to the operating system, wherein the memory device receives the new process, a lookup table that includes both the identifier and endpoint of the new process, wherein the lookup table is in communication involving other processes. The controller or control process informs a previous process to perform a non-disruptive switchover to the new process. The apparatus can further include a downloader linked to the memory device, wherein the new process is received by the downloader and placed in the memory device.
In another aspect of this embodiment, signals are sent between the old process and the new process. The signal can include the database of the previous process and the identifier of the new process.
Once the database is transferred to the new process, the control process is alerted to this occurrence. In the endpoint lookup table, an identification number entry for the previous process's end point is replaced by the new process's identification number.
There has thus been outlined, rather broadly, the more important features of the invention in order that the detailed description thereof that follows may be better understood, and in order that the present contribution to the art may be better appreciated. There are, of course, additional features of the invention that will be described below and which will form the subject matter of the claims appended hereto.
In this respect, before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not limited in its application to the details of construction and to the arrangements of the components set forth in the following description or illustrated in the drawings. The invention is capable of other embodiments and of being practiced and carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein, as well as the abstract, are for the purpose of description and should not be regarded as limiting.
As such, those skilled in the art will appreciate that the conception upon which this disclosure is based may readily be utilized as a basis for the designing of other structures, methods and systems for carrying out the several purposes of the present invention. It is important, therefore, that the claims be regarded as including such equivalent constructions insofar as they do not depart from the spirit and scope of the present invention.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram illustrating several elements of a preferred embodiment of the present invention.
FIG. 2 is a diagram illustrating specific elements of the preferred embodiment.
FIG. 3 is a block diagram of an alternate embodiment of the present invention.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION
A preferred embodiment of the present invention provides an apparatus for downloading executable code to a system device and running or executing it after download, in a manner that the system device being upgrade is always available to other system devices. This allows the system to continue to operate without the need to sacrifice valuable processing time.
A general operating system supports multithreads of execution to create a multitasking environment. The operating system OSE from Enea of Sweden refers to these multithreads as processes. OSE operating system categorizes processes into categories such as dynamic, and static. The dynamic process, supported by OSE, is a focal point of this invention. The dynamic process, according to OSE, is a process that can be dynamically created and then destroyed. In other words, it is possible to create or spawn a process and then at a later point in time delete this process.
The present invention focuses on two types of dynamic processes, (i) loadable; and (ii) persistent. This invention does not allow persistent process to be non-disruptively loaded and started. All OSE processes are persistent. User processes can be loadable or persistent. On the other hand, loadable processes are capable of being non-disruptively loaded and started. The following is a breakdown of the hierarchy of the processes:
FIG. 1 is a block diagram illustrating several elements of a preferred embodiment of the present invention. A new or upgraded process 102 is compiled outside of the system 104. The new process 102 comprises an endpoint 108 (same as an endpoint of previous process 118) and a database 106. The endpoint 108 is in addition to the process identification that is generated by the operating system executable code 110. In the present invention the operating system executable code 110 can be the OSE operating system.
The new process 102 is downloaded into the system 104 via the downloader 112 to eventually replace process A 118. In the present invention, the downloader 112 can be the dynamic program-loading feature of OSE. The downloader 112 allows a user to load the new process 102 or code into memory 114 without disrupting currently running processes.
Any process loaded or currently located in the OSE operating system is identified by its identifier or process ID code. The identifier is a unique number to identify a particular process. The identifier is assigned and created by the OSE operating system when the process is loaded and executed into the system device 104. The identifier cannot be user specified.
In the OSE operating system, each process has one input queue to receive signals. The signal is a message containing information that usually results in work for the process. In other words, the signal is a request for the process to perform a certain function. Since there is only one input queue to receive signals, there is only one input queue per process. The same identifier is also used to identify the input queue of a process.
The current invention places an additional layer on top of the OSE operating systems identifier to identify processes and queues. This layer is labeled as an endpoint 108. The endpoint 108 is created at the time the new process 102 is compiled and not by the OSE operating system or the operating system executable code 110. The endpoint 108 enables the previous processes 118, 120, 122 to communicate with one another. The endpoint 108, as an identifier, is unique for a given process, but is similar if not the same for previous and new versions of the process. The similarity of the endpoints ensures seamless upgrading of the process. Processes already resident in the system are not required to obtain a new endpoint for the upgraded process. One of the differences between the identifier and the endpoint 108 is that the endpoint 108 is determined at compile time rather than at runtime and the identifier is generated at runtime.
The OSE processes and the new process 102 communicate with each other through the use of the identifier. It is not necessary to alter this communication mechanism because the OSE processes are not capable of being non-disruptively upgradeable. Furthermore, if an OSE process communicates to a new process 102 on a regular basis, that new process 102 becomes persistent and then is unable to be non-disruptively upgraded. In the present invention, only a small percentage of the previous processes 120, 122 are or become persistent. As mentioned before, new process 102 will eventually replace process A 118.
The new process 102 includes a database 106 and an endpoint 108. The database 106 can be initially set at the default setting or can be left blank. The new process 102 is received by the downloader 112, which is part of the system 104. The downloader 112 places the new process 102 into memory 114. At this point, the process 102 is started or executed by the OSE operating system 110. Additionally, the OSE operating system 110 generates an identifier with the ID generator 116.
The new process 102 is loaded into memory 114 where it is then executed to eventually replace or upgrade the previous process A 118. As stated previously, the new process 102 includes an endpoint 108, which is generated at compile time of the executable code, and a database 106 that is initially non-existent, set to a default setting or empty.
Once the new process 102 is loaded into memory 114, the ID generator 116 of the operating system 110 generates an identifier for the new process and placed into the database 106. A non-disruptive code load (NDCL) control process 124 or controller then communicates to the downloader 112 to obtain a list of new identifiers. The NDCL control process 124 informs previous process A 118 to perform a non-disruptive switchover to the new process 102. Contained in this signal payload is the identifier of the corresponding loadable new process 102. The passing or communicating of the identifier of the new process 102 to the previous process 118 allows these two processes to communicate with each other directly without the need to update the endpoint lookup table.
The previous process 118 transmits data to the new process 102 to enable the new process 102 to update its database 106. In the present invention, these update signals are not altered during code revisions. This enables the update signals to be translated by any version of new process.
The new process 102, upon receiving the update signals, updates its database 106. During this period of time, the new process 102 does not receive any requests from other sources to perform certain functions. The previous process 118 continues to service and process new requests as it sends update signals to the new process 102. Furthermore, the previous process 118 sends new update signals as its own internal database 126 is altered or changed from new requests from other processes.
Once the previous process A 118 has completed the database transfer, the previous process A alerts the NDCL control process 124. At this point in time, the database 106 of the new process 102 is sufficiently similar to the database 126 of the previous process 118 such that the new process can seamlessly function as the previous process. The NDCL control process 124 then proceeds to update an endpoint lookup table 130 with the identifier of the new process 102 replacing the identifier 128 of the previous process A 118. Furthermore, the previous process A 118 forwards any remaining work on its queue to the new process 102, From this point forward, all new work or requests are being directed to the new process 102. The previous process A 118 can be deleted to free additional memory in the system 104. As previously stated, the endpoint 108 for the previous process 118 and new process 102 remains similar if not identical through an upgrade. The endpoint lookup table 130 completes the conversion for other processes to communicate with the upgraded process. In other words, the processes already resident in a system specify an upgradeable process by a known endpoint 108. This request to communicate with the other process by identifying the endpoint is then received by the endpoint lookup table 130, which in turn identifies the new process 102 by its identifier. The step of updating the process identifier in the endpoint lookup table for an upgraded process bypasses each process having to know the process identifier of pervious and new processes as well as ensuring a fast and efficient means for a nondisruptive code load.
Note that it is possible for processes to be in a different formats because of differing code versions. However, these processes are still able to communicate with each other. The new process 102 is both forward and backward compatible with the differing code revisions in order to communicate and transfer data.
FIG. 2 is a diagram illustrating the specific elements of the preferred embodiment. Consider a running system that includes both persistent and loadable processes running. All processes are communicating to each other by the use of signals being placed on their receive queues. The OSE operating system identifies queues by their identifier. The present invention places an additional identification layer on top of the OSE operating system identifier to enable processes to identify specific processes and queues. This new layered identification is called an endpoint 108 and is the way processes, loadable and persistent, communicate with each other.
If an existing process A 202 needs to send a message to an existing process B 204, then process A 202 specifies the endpoint 108 of process B 204. The process A 202 proceeds to lookup the endpoint 108 in the endpoint lookup table 130. Once the endpoint 108 of process B 204 is discovered, the endpoint 108 is translated into a process identifier and then the message from process A 202 is routed to the process B 204. The endpoint lookup table 130 is comprised of all the identifiers for the processes. The endpoint lookup table 130 allows processes to free up memory space by letting one central location store the common information. This centralization is also useful for updating such that only one table needs to be updated and thus there are no race conditions. In FIG. 2, the endpoint 108 of process A 202 is not the same endpoint 108 of process B 204. FIG. 2 illustrates the preferred embodiment of communication between two loadable processes.
FIG. 3 is a block diagram of an alternate embodiment of the present invention. FIG. 3 is a block diagram illustrating a method of the present invention. This alternate embodiment is begun with the step 302 of loading a new process 102 into memory 114. The new process contains at the minimum an endpoint 108. The next step 304 involves starting or executing the new process 102. At this point, the new process 102 is present in memory 114 but not processing requests or messages. The OSE operating system 110 initiates the step 306 of creating an identifier for the new process 102 once the new process 102 or executable code is loaded into memory 114.
Once loaded into memory 114, an NDCL control process 124 begins the step 308 of communicating with the downloader 112 to obtain the identifier of any and all new processes 102. The NDCL control process 124 performs the step 310 of informing the previous process 118 to initiate a switchover the new process 102. After the previous process 118 receives this request, the previous process 118 begins the step 312 of transmitting data to the new process 102. The data can be the internal database 126 of the previous process 118. The new process 102 uses this data to update its database 106 in preparation for replacing the previous process 118. Once all the data has been transmitted by the previous process 118, the previous process 118 performs the step 314 of informing the NDCL control process 124 that the database has been transferred. In response, the NDCL control process 124 executes the step 316 of updating the endpoint look table 130 with the endpoint 108 of the new process 102. After which, NDCL control process 124 informs pervious process 118 to forward all remaining requests on its queue to new process 102. Previous process 118 executes step 317 and carries out the fowarding of all pending requests on its queue to the new process 102. At this point, the new process 102 begins the step 318 of processing all requests. The NCDL control process 124 can perform the step 320 of removing the previous process 118 from memory 114.
It is also contemplated by the present invention to upgrade interrupt handlers in a non-disruptive fashion. This is possible because the interrupt handlers are called or retrieved from a vector table. The current implementation of OSE requires that during the upgrade of the interrupt handlers that the interrupts be disabled when changing the function point in the vector table. The preferred embodiment implements the upgrading of interrupts by disabling the interrupts. However, the invention is not limited to such a configuration. One of ordinary skill in the art recognizes that it is possible to implement the present invention without the need to disable interrupt. With the present invention, this period of time when the interrupts are disabled is exceedingly fast, less than 500 microseconds. During this time, the hardware interrupts are stacked. When the interrupt handlers are upgraded, the interrupts are handled by the new handlers. The interrupt handlers do not have internal databases, so there is no need to synchronize old and new code.
The many features and advantages of the invention are apparent from the detailed specification, and thus, it is intended by the appended claims to cover all such features and advantages of the invention, which fall within the true spirits, and scope of the invention. Further, since numerous modifications and variations will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and operation illustrated and described, and accordingly, all suitable modifications and equivalents may be resorted to, falling within the scope of the invention.
Patent applications by Naresh Talati, Voorhees, NJ US
Patent applications in class SOFTWARE UPGRADING OR UPDATING
Patent applications in all subclasses SOFTWARE UPGRADING OR UPDATING