Detecting impact of operating system upgrades

Methods, systems, and products for detecting impact of operating system upgrades on software components. Embodiments detect the impact of differences between a current operating system and an upgraded operating system. The operating system is configured to provide a run-time environment. In one embodiment, a method comprises detecting a call from a software entity running on a first data processing system to the current operating system of the data processing system; recording the detected call in a data structure configured to contain one or more recorded calls; scanning the upgraded operating system on a second data processing system upon which the upgraded operating system is installed and running, before execution of the software entity in the run-time environment of the upgraded operating system, to identify the recorded calls in the data structure that are not supported by the upgraded operating system; and presenting an indication of the identified calls.

BACKGROUND

In modern data processing systems, or computers, an operating system manages the distribution of system resources to various processes benefiting the user, such as, for example, user-interfaces accepting specific tasks from the user or higher-level applications providing more complex benefits. Processes running in a user space (or application space) do not have permission to utilize the system's resources on their own. Operating systems provide entry points through system calls, which may be implemented using software interrupts, that allow user-level processes to request services from the kernel. Thus, these processes make predefined calls to the operating system to request resources from the operating system. The processes may be configured to make calls directly or by making calls to an application program interface (‘API’) which implements system calls. System calls and API calls may be implemented differently on various operating systems, or on different versions of the same operating system.

SUMMARY

Methods, systems, and computer program products for detecting impact of operating system upgrades on software components are disclosed herein. Embodiments of the present disclosure detect the impact of differences between a current operating system and an upgraded operating system. The operating system is configured to provide a run-time environment. Generally, embodiments of the invention operate to detect the invocation of operating system calls via scripts, commands, functions, and applications and record these operating system calls in a data structure. The data structure thus keeps a current record of the calls being used in the current operating system and the software entity (script, command, function, application, etc.) from which any particular call originates. This record is then used to identify previously used calls that are not supported by the upgraded operating system. Upon identification, these unsupported calls may be replaced with supported mechanisms having similar functionality. The calls may be identified before execution of the software entity in the environment of the upgraded operating system, so as to avoid incompatibility errors.

In some embodiments of the present disclosure, the data structure is exported to a separate data processing system having the upgraded operating system installed, and scanning occurs on the second system. This scanning may occur before installing the upgraded operating system on the first data processing system.

In some embodiments of the present disclosure, scanning takes place on the original data processing system. If the installation of the upgraded operating system is destructive, the data structure is transferred to a separate data processing system or a storage medium and then reloaded after the installation is completed. If the installation is non-destructive, the data structure may remain on the original data processing system.

In a first general embodiment, a method comprises detecting a call from a software entity running on a first data processing system to the current operating system of the data processing system; and recording the detected call in a data structure configured to contain one or more recorded calls. Recording the detected calls in the data structure may be carried out by listing the detected calls in the data structure such that a particular call is listed in the data structure only once. Recording the detected calls in the data structure may include listing a particular call in the data structure and associating the particular call with the software entity from which the call originated.

In a second general embodiment, a method comprises scanning the upgraded operating system on a second data processing system upon which the upgraded operating system is installed and running. Scanning takes place before the execution of the software entity in the run-time environment of the upgraded operating system. Scanning identifies the recorded calls in the data structure that are not supported by the upgraded operating system. The second data processing system may present an indication of the identified (non-supported) calls. In selected embodiments, the indication of the identified calls may include any of the name of the call, an unique identifier indicating the call, or the name or other identifier of the software entity from which the call originated.

In selected embodiments, scanning the upgraded operating system may be performed prior to installation of the upgraded operating system on the first data processing system, or without the software entity being installed on scanning data processing system.

Other general embodiments include a system comprising one or more data processing systems. The data processing systems comprise a processor and a computer memory operatively coupled to the processor. The computer memory has disposed within it computer program instructions for execution on the processor to implement one or more of the method embodiments described above. Other embodiments include computer program products disposed on a computer readable medium comprising computer program instructions for carrying out one or more of the method embodiments described above by their execution on a computer processor.

DETAILED DESCRIPTION

FIG. 1Aillustrates a direct operating system call from a software entity to the current operating system in accordance with one embodiment of the invention. Referring toFIG. 1A, a software entity104executing in a user mode102invokes an instance of System Call A106. The software entity104may be a script, a shell command executed from a command line interface, a service, a software application, or any other software entity capable of invoking a system call as will occur to those of skill in the art.

The instance of System Call A106, when invoked by software entity104, requests an implementation of System Call A112in kernel mode114through a system call interface108. The system call interface108provides a software interface to services provided by the operating system and defines all the services of the operating system to software entities running in user mode102, such as software entity104. The system call interface108may include a system call table that has pointers to the functions that implement the system calls inside the kernel. The system call table provides a well-defined interface to the operating system services.

FIG. 1Billustrates an indirect operating system call from a software entity to the current operating system of the data processing system via an application program interface (‘API’) in accordance with one embodiment of the invention. Referring toFIG. 1B, the system call is made by an instance of API Call A116to an API library118implementing an API, such as, for example, a Win32 API, a POSIX API, a Java API, etc. APIs may use system calls to perform various tasks within the system kernel. The instance of API Call A116, when invoked by software entity104, causes API Call A to request an implementation of System Call A112in kernel mode114through the system call interface108by invoking an instance of System Call A106. As used herein, an operating system call from a software entity to the current operating system, generally, may refer to either a direct (FIG. 1A) or indirect (FIG. 1B) system call.

Invoking System Call A operates to request privileged operations from the operating system, such as input/output (‘I/O’) to system devices or communication with other processes. System Call A may be one of many exemplary system calls, such as, for example, open, read, write, close, wait, exec, fork, exit or one of hundreds of other system calls found in operating systems. After executing, the implementation of System Call A112returns (directly or indirectly) to software entity104running in user mode102.

Operating systems may be frequently upgraded. Often, system calls previously invoked by software installed on a computer running a current operating system are no longer supported by an upgraded operating system. That is, the current system call does not exist in the upgraded operating system (or corresponding system call interface), although an implementation of services similar or identical to the current system call's services may be invoked by a new system call. Invoking a non-supported system call may lead to an error.

Embodiments of the invention discover non-supported operating system calls to an operating system from software entities (e.g. script, shell command, shell command option, application) before the system calls are invoked by the upgraded operating system, and present the non-supported call along with the software entity invoking the call. This allows users or administrators to change the non-supported system calls in software entities before an error is caused.

Embodiments of the presently disclosed invention are implemented to some extent as software modules installed and running on one or more data processing systems (‘computing devices’), such as servers, workstations, tablet computers, PCs, personal digital assistants (‘PDAs’), smart phones, and so on.FIG. 2sets forth a block diagram of an exemplary computer202. Computing device202includes at least one computer processor254as well as a computer memory, including both volatile random access memory (‘RAM’)204and some form or forms of non-volatile computer memory250such as a hard disk drive, an optical disk drive, or an electrically erasable programmable read-only memory space (also known as ‘EEPROM’ or ‘Flash’ memory). The computer memory is connected through a system bus240to the processor254and to other system components. Thus, the software modules are program instructions stored in computer memory.

An operating system208is stored in computer memory. Operating system208may be any appropriate operating system such as Windows XP, Windows Vista, Mac OS X, UNIX, LINUX, or AIX from International Business Machines Corporation (Armonk, New York).

Computing device202also includes one or more input/output interface adapters256. Input/output interface adapters256may implement user-oriented input/output through software drivers and computer hardware for controlling output to output devices272such as computer display screens, as well as user input from input devices270, such as keyboards and mice.

Computing device202also includes a communications adapter252for implementing data communications with other devices260. Communications adapter252implements the hardware level of data communications through which one computer sends data communications to another computer through a network.

Also stored in computer memory is an incompatibility discovery module206. The incompatibility discovery module206may include computer program instructions for detecting instances of one or more calls from a software entity running on a data processing system to the current operating system of the data processing system; and computer program instructions for recording the detected calls in a data structure. In some implementations, the incompatibility discovery module206also includes computer program instructions for scanning the upgraded operating system, before the software entity is executed in the environment of the upgraded operating system, to identify calls recorded in the data structure that are not supported by the upgraded operating system; and computer program instructions for presenting an indication of the identified calls.

Incompatibility discovery module206may be implemented as one or more sub-modules operating in separate software layers or in the same layer. Although depicted as a separate module from the operating system inFIG. 2, the incompatibility discovery module206or one or more of the sub-modules may be incorporated as part of the operating system208. In some embodiments, the incompatibility discovery module206may be implemented in the software stack, in hardware, in firmware (such as in the BIOS), or in any other manner as will occur to those of ordinary skill in the art.

For further explanation.FIG. 3sets forth a data flow diagram illustrating an exemplary software architecture for discovering software incompatibilities. The software architecture ofFIG. 3includes an operating system208(seeFIG. 2above). A detection module308is installed by a user or administrator for use with the current operating system. The detection module308starts automatically and also runs after reboot. After installation, as an operator uses the system normally, the detection module308detects instances of operating system calls from software entities302. A recording module310is installed with the detection module308. The recording module310records the detected calls in a data structure312. The recording module310may also record additional data connected to the recorded call. The data structure may be a database, a matrix, a file, or any other data structure. The data structure may be readily portable. In some implementations, such as when installing the upgraded operating system using a destructive overwrite, a user or administrator may transfer the data structure to media, such as a CD or DVD; or to network file systems such as an Andrew File System (‘AFS’). Distributed File System (‘DES’), or Network File System (‘NFS’). The detection module308, the recording module310, or both may be implemented as a low-level background process, such as a daemon or service, and may also be combined in a single module. For example, the low-level process may be a kernel process.

The software architecture also includes a scanning module306, which scans the upgraded operating system314to identify recorded calls that are not supported by the upgraded operating system314. Identified calls may be passed to the presentation module304or stored for later access by the presentation module304. An administrator may install the scanning module306with the detection module308, or it may be installed later. The system architecture ofFIG. 3implements the scanning module306on the same data processing system on which the detection module is installed. In this implementation, scanning may take place after the installation of the upgraded operating system314on the computing device202(right of line320). As shown inFIG. 3, if the installation of the upgraded operating system314utilizes a destructive overwrite, the scanning module306installation takes place after the upgraded operating system installation. For non-destructive operating system installations (e.g. migrations), the user or administrator may install the scanning module with the other modules (not shown).

Although the system architecture as depicted inFIG. 3utilizes only one data processing system, scanning the upgraded operating system may take place on a second (separate) data processing system before the upgraded operating system is installed on the original data processing system, as described in further detail with reference toFIG. 6below. The architecture of the second data processing system in such an implementation (not shown) may omit the detection module308, the recording module310, or both.

The software architecture also includes a presentation module304that presents an indication of the identified calls. The identified calls are received from the scanning module or retrieved from storage. Presentation module304may contain a user interface component (not shown), such as a graphical user interface (‘GUI’) component. The GUI component may enable users or administrators to change the manner of presentation by typing on a keyboard and manipulating displayed graphical elements with a mouse.

FIG. 4is a data flow diagram illustrating one embodiment of a method for discovering software incompatibilities created by differences between a current operating system and an upgraded operating system in accordance with one embodiment of the invention. In FIG.4, incompatibility discovery module206detects a call406from a software entity running on a data processing system to the current operating system of the data processing system (block404). Detecting a call406may be carried out by intercepting calls to the interface. For example, the detection module may intercept calls by exploiting a kernel extension of the operating system, by using replacement functions in a library, by using a stub module wrapping an API call, or by other interception techniques as will occur to those of skill in the art. In response thereto, the detection module (FIG. 3,308) stores the calls or forwards them to a recording module. The data structure408thereby contains calls employed previously by users of the system, so that analysis is tailored to each user and the software entities the user employs.

Still referring toFIG. 4, the incompatibility discovery module206records the detected call in a data structure408configured to contain one or more recorded calls410(block406).FIG. 5Ais a data flow diagram illustrating recording the detected calls in a data structure in accordance with one embodiment of the invention. Referring toFIG. 5A, recording the detected calls in a data structure408(block406) may be carried out by listing the detected calls in the data structure such that a particular call is listed in the data structure only once (block504). Thus, redundant data is not tracked. In contrast to logging every call, listing the detected calls only once avoids redundant calls and saves overhead. Recording the detected calls in a data structure408(block406) may also include listing a particular call in the data structure (block502) and associating the particular call with the software entity from which the call originated (block506). For example, if a script calls a command thousands of times, the data structure may only list the call and the script and indicate that the instance occurred at least once. Associating the particular call with the software entity from which the call originated may be carried out by collecting data on the system calls by employing standard utilities such as, for example, strace.

For further explanation, consider exemplary data structure408. Each of System Call A, System Call X, System Call D, System Call G, and System Call C is listed in data structure408because each has been called at least once. System Call A is associated with Command1, which is the software entity that called System Call A, either directly or indirectly. Similarly, System Call X is associated with Script2, System Call D is associated with Command12, System Call G is associated with Script3, and System Call C is associated with Command7. In some implementations, more than one software entity may be associated with each system call (not shown). An API call may also be associated with a system call. In some embodiments, detecting and recording system calls may include tracking and recording a total number of times a system call is called, a software entity makes any system call, a software entity makes a particular system call, and so on.

Returning toFIG. 4, the incompatibility discovery module206scans the upgraded operating system412to identify recorded calls410in the data structure408that are not supported by the upgraded operating system412. Scanning the upgraded operating system412is carried out before the software entity is executed in the environment of the upgraded operating system412. In some implementations, scanning the upgraded operating system412is carried out prior to the installation of the upgraded operating system412on the data processing system.

The method also includes presenting an indication of the identified calls (block416). The indication of the identified call may be textual output including software entities (such as commands and scripts) associated with the identified calls, the identified calls themselves, and/or combinations or subsets of these calls and software entities, and so on. The indication may include a file, a report, a dialog box, a flag, a visual indicator, an alert sound, or any other I/O mechanism that alerts or informs another data processing system, a user, or an administrator that an incompatibility has been discovered. In some implementations, the presentation module may sort the identified calls or associated software entities according to one or more criteria for presentation. Criteria could include, for example, number of times a call is invoked, number of software entities invoking a call, types of call, category of software entity (command, script, application, etc.), priority, all calls invoked by a specific software entity or set of software entities, all software entities invoking a specific call or set of calls, and so on.

FIG. 5Bis a diagram illustrating a graphical display for presenting an indication of the identified calls in accordance with one embodiment of the invention. Referring toFIG. 5B, graphic display510includes text representations of the software entities512which when executed invoked an identified call514that is non-supported by the upgraded operating system. The text representation of the software entities512is graphically associated with the identified call514. For example, “Command1” is displayed on a same line as “System Call A”, indicating that System Call A is contained within Command1. Other graphical associations may be used, such as columns, boxes, separate tabs, separate pages, and so on.

FIG. 6is a data flow diagram illustrating a method for discovering software incompatibilities in accordance with one embodiment of the invention. The method includes detecting calls302(block610) and recording a detected call in a data structure308(block612) in a first data processing system602as described above with reference toFIG. 4.

The method further includes exporting the data structure308from the first data processing system602before installation of the upgraded operating system on the first data processing system602(block614). The data structure may be exported directly to a second data processing system604or stored on media or a file system (as described above with reference toFIG. 4) before being exported to the second data processing system604. The method may also include importing the data structure310to the second data processing system (block608). The incompatibility discovery module206scans the upgraded operating system412to identify calls in the data structure that are not supported by the upgraded operating system412(block616). Scanning the upgraded operating system412may include scanning the upgraded operating system412prior to the installation of the upgraded operating system412on the first data processing system602.

The method ofFIG. 6also includes presenting indications of identified calls (block618), such as, for example, displaying text naming the software entities invoking the identified calls, as described above. AlthoughFIG. 6depicts presenting indications of identified calls (block618) occurring on the second data processing system604, presenting may alternatively be performed on the first data processing system602.

It should be understood that the inventive concepts disclosed herein are capable of many modifications. Such modifications may include combinations of hardware and software embodiments, specific circuit designs, combinations of circuits into an IC, separation of an IC into various components, and so on. To the extent such modifications fall within the scope of the appended claims and their equivalents, they are intended to be covered by this patent.