Detecting software incompatibilities within a system stack

Embodiments of the invention are directed to methods and systems for detecting incompatibilities in a computer system. The method includes logging incoming requests to a target component; receiving changes to the target component; analyzing the changed target component; performing a simulation to determine the compatibility of the target component with respect to one or more other components, and upon the finding of an incompatibility causing a notification.

BACKGROUND

The present invention relates in general to the field of computing. More specifically, the present invention relates to systems and methodologies for detecting software incompatibilities within a system stack.

In modern computing systems, computer software is occasionally updated for a variety of reasons. The software might be updated to provide additional functionality, to maintain compatibility with new versions of an operating system, or to fix various issues. A change to one piece of software can impact other pieces of software or other hardware, sometimes in manners not readily foreseeable. A software developer can be interested in seeing how their changes affect other portions of a computer system.

SUMMARY

Embodiments of the invention are directed to methods and systems for detecting incompatibilities in a computer system. The method includes logging incoming requests to a target component; receiving changes to the target component; applying the changes to the target component to create a changed target component; analyzing the changed target component; performing a simulation to determine the compatibility of the target component with respect to one or more other components, and upon a finding of an incompatibility causing a notification.

Embodiments of the present invention are further directed to a computer system for recommending software updates. The system includes a memory and a processor system communicatively coupled to the memory. The processor is configured to perform a method that includes logging incoming requests to a target component; receiving changes to the target component; applying the changes to the target component to create a changed target component; analyzing the changed target component; performing a simulation to determine compatibility of the target component with respect to one or more other components; and upon a finding of an incompatibility causing a notification.

Embodiments of the invention are directed to methods and systems for detecting incompatibilities in a computer system. The method includes installing a target component onto a computer system; logging incoming requests to the target component; analyzing the target component to determine compatibility of the target component with respect to one or more other components of the computer system; upon a finding of an incompatibility determining severity of the incompatibility; and providing one or more recommendations for alleviating the incompatibility based on the determined severity.

Additional features and advantages are realized through techniques described herein. Other embodiments and aspects are described in detail herein. For a better understanding, refer to the description and to the drawings.

DETAILED DESCRIPTION

Turning now to an overview of technologies that are more specifically relevant to aspects of embodiments of the invention, as described above, computer systems include both hardware and software. The software can include both an operating system and application programs. Software is periodically updated for a variety of different reasons. Commonly, those reasons can include the addition of new features, support of new hardware, and bug fixes that solve various issues with the software.

In a computer system (also known as a “system stack”) with many software components communicating with each other and with hardware, it can be difficult to assess a change to a first software component will have on any other software component when. Other components (both software and hardware) may rely on specific defaults, application program interface (API) outputs, memory sizes, and the like. Making a change to the first software component can cause incompatibilities to other components that expect a different behavior from the first software component. If incompatibilities are not accounted for, there is a possibility that one or more pieces of software will not operate properly.

Turning now to an overview of the aspects of embodiments of the invention, one or more embodiments of the invention address the above-described shortcomings of the prior art by logging and collecting communications between the first software component and other components operating on the system stack and analyzing code changes to detect potential incompatibilities.

A flowchart illustrating method100is presented inFIG. 1. Method100is merely exemplary and is not limited to the embodiments presented herein. Method100can be employed in many different embodiments or examples not specifically depicted or described herein. In some embodiments, the procedures, processes, and/or activities of method100can be performed in the order presented. In other embodiments, one or more of the procedures, processes, and/or activities of method100can be combined or skipped. In one or more embodiments, method100is performed by a processor as it is executing instructions. In some embodiments, method100is performed by computer system300.

Software is installed on a computer system (block102). The installed software is software capable of operating an embodiment. In some embodiments, the computer system resembles a production environment. “A production environment” is a computer system with a configuration similar to that of computer systems that a component will be installed on. Sometimes, software developers use specialized systems to code their components, where the specialized system might not be similar to the systems in which the component will be installed. A production environment is a computer system that is closer to the type of computer system that a user will use with the component.

The software is configured to log incoming requests to the target component (block104). In some embodiments, more than one component can be chosen as the target component. In some embodiments, the logging can be configured to occur only for a specified period of time. The incoming requests can include what macros, APIs, and functions are being called and the parameters used when called. In some embodiments, the type of requests being logged can be configured. Some developers might not desire the level of granularity provided by logging each function call and may only desire logging of APIs. In some embodiments, the results of each call also can be logged. The specified time also can be adjusted. All calls made during the specified time can be collected. The information collected can include the calling component's name, the parameters to the requesting function, and the results returned to calling component. In addition, there can be a configurable collection of arbitrary information available at the time of the call.

As the developers make changes to the functionality of the target component (block106), an analysis of the target component is made (block108), and simulations are executed to test the compatibility of the changes against previously logged requests (block110). The analysis determines changes to the functions, APIs, and service calls. The simulations detect potential impact to other components. The simulations are performed using the parameters gathered in block104. Using the simulations, an embodiment can determine if another component will receive unexpected results from their call to the target component. The unexpected result can be deemed an “incompatibility.”

If an incompatibility is found it is flagged for investigation (block112), and a notification is generated (block114). The notification can inform a developer of the incompatibility. In some embodiments, the notification can include details as to exactly what functions are causing the incompatibility. In addition, the notification can include suggestions as to how to alleviate the incompatibility.

In some embodiments, a user can determine a severity of an incompatibility for a potential component update. A flowchart illustrating method200is presented inFIG. 2. Method200is merely exemplary and is not limited to the embodiments presented herein. Method200can be employed in many different embodiments or examples not specifically depicted or described herein. In some embodiments, the procedures, processes, and/or activities of method200can be performed in the order presented. In other embodiments, one or more of the procedures, processes, and/or activities of method200can be combined or skipped. In one or more embodiments, method200is performed by a processor as it is executing instructions. In some embodiments, method200is performed by computer system300.

A software update (also known as a patch or a target component) is initiated onto a system (block202). A simulation is run (using, for example, a method described with respect toFIG. 1) (block204). If an incompatible change is detected, then a severity of the incompatibility is determined (block206). For example, if the affected component merely returns a different error message, the incompatibility can be noted as a low-severity incompatibility. But if the incompatibility affects serialized resources in multiple locations, it could be noted as a high-severity incompatibility. In some embodiments, the severity can be assigned a score. If the severity is above a certain threshold, the software is determined to be high-severity. In some instances, if the severity is high enough, the system can block the install from being completed.

In addition to detecting compatibility issues, different versions of conflicting components can be analyzed (block208). Analyzing different versions can include a variety of different tasks. For example, multiple versions can be analyzed to find a version with no incompatibilities. In other words, if a newer version introduced an incompatibility, it can be determined at what point in the process it was last compatible.

Thereafter, suggestions can be determined as to versions of components that will create the least amount of incompatibility (block210). This can be accomplished by obtaining multiple versions of the components and performing simulations with each version of the conflicting components. A score can be assigned and the lowest score can be chosen as the versions that create the least amount of incompatibility. Thereafter, suggestions can be generated for upgrading or downgrading one or more of the conflicting components to minimize any incompatibilities (block212). The generated suggestions can be provided to the user (block214).

FIG. 3depicts a high-level block diagram of a computer system300, which can be used to implement one or more embodiments. More specifically, computer system300can be used to implement hardware components of systems capable of performing methods described herein. Although one exemplary computer system300is shown, computer system300includes a communication path326, which connects computer system300to additional systems (not depicted) and can include one or more wide area networks (WANs) and/or local area networks (LANs) such as the Internet, intranet(s), and/or wireless communication network(s). Computer system300and additional system are in communication via communication path326, e.g., to communicate data between them.

Computer system300includes one or more processors, such as processor302. Processor302is connected to a communication infrastructure304(e.g., a communications bus, cross-over bar, or network). Computer system300can include a display interface306that forwards graphics, textual content, and other data from communication infrastructure304(or from a frame buffer not shown) for display on a display unit308. Computer system300also includes a main memory310, preferably random access memory (RAM), and can also include a secondary memory3120. Secondary memory312can include, for example, a hard disk drive314and/or a removable storage drive316, representing, for example, a floppy disk drive, a magnetic tape drive, or an optical disc drive. Hard disk drive314can be in the form of a solid state drive (SSD), a traditional magnetic disk drive, or a hybrid of the two. There also can be more than one hard disk drive314contained within secondary memory312. Removable storage drive316reads from and/or writes to a removable storage unit318in a manner well known to those having ordinary skill in the art. Removable storage unit318represents, for example, a floppy disk, a compact disc, a magnetic tape, or an optical disc, etc. which is read by and written to by removable storage drive316. As will be appreciated, removable storage unit318includes a computer-readable medium having stored therein computer software and/or data.

In alternative embodiments, secondary memory312can include other similar means for allowing computer programs or other instructions to be loaded into the computer system. Such means can include, for example, a removable storage unit320and an interface322. Examples of such means can include a program package and package interface (such as that found in video game devices), a removable memory chip (such as an EPROM, secure digital card (SD card), compact flash card (CF card), universal serial bus (USB) memory, or PROM) and associated socket, and other removable storage units320and interfaces322which allow software and data to be transferred from the removable storage unit320to computer system300.

Computer system300can also include a communications interface324. Communications interface324allows software and data to be transferred between the computer system and external devices. Examples of communications interface324can include a modem, a network interface (such as an Ethernet card), a communications port, or a PC card slot and card, a universal serial bus port (USB), and the like. Software and data transferred via communications interface324are in the form of signals that can be, for example, electronic, electromagnetic, optical, or other signals capable of being received by communications interface324. These signals are provided to communications interface324via a communication path (i.e., channel)326. Communication path326carries signals and can be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link, and/or other communications channels.

In the present description, the terms “computer program medium,” “computer usable medium,” and “computer-readable medium” are used to refer to media such as main memory310and secondary memory312, removable storage drive316, and a hard disk installed in hard disk drive314. Computer programs (also called computer control logic) are stored in main memory310and/or secondary memory312. Computer programs also can be received via communications interface324. Such computer programs, when run, enable the computer system to perform the features discussed herein. In particular, the computer programs, when run, enable processor302to perform the features of the computer system. Accordingly, such computer programs represent controllers of the computer system. Thus it can be seen from the foregoing detailed description that one or more embodiments provide technical benefits and advantages.

Referring now toFIG. 4, a computer program product400in accordance with an embodiment that includes a computer-readable storage medium402and program instructions404is generally shown.

Embodiments can be a system, a method, and/or a computer program product. The computer program product can include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to carry out aspects of embodiments of the present invention.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The descriptions presented herein are for purposes of illustration and description, but is not intended to be exhaustive or limited. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of embodiments of the invention. The embodiment was chosen and described in order to best explain the principles of operation and the practical application, and to enable others of ordinary skill in the art to understand embodiments of the present invention for various embodiments with various modifications as are suited to the particular use contemplated.