Browse Prior Art Database

Compatibility layer

IP.com Disclosure Number: IPCOM000220918D
Publication Date: 2012-Aug-15
Document File: 2 page(s) / 53K

Publishing Venue

The IP.com Prior Art Database

Abstract

A compatibility layer for communication of resource information between dissimilar versions of the same software such that resource renumbering, deletion and renaming can be handled without undesirable effects due to resource clashes.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 2

Compatibility layer

In a redundant subsystem such as a SCSI enclosure there will be two (or more) subcomponents running firmware that need to have a common understanding of resources and functionality. In good path conditions the subcomponents will be running the same level of code and will transfer information between themselves based on this knowledge. This means they will have the same view of what is supported and where to find particular resources. One bad path scenario is that the subcomponents will be running different levels of code. This may mean that they now have different views of what is supported and where to find resources. It can also mean that resources have been rearranged so they may think they know where a resource is but in reality that resource can have moved or been removed.

    In the standard implementation, one side is running code load 1000 and knows that resource 23 is some VPD. It makes a request of its partner using the resource number. Its partner is running code load 2000 and it knows resource 23 as a GPIO. What will result from this query is at best undefined.

    A typical solution to this problem is to not allow transfer of information but this means the product is running in a degraded or sub-normal state and may restrict the level of functionality available. An alternative solution is to define a support level which gives a way of deciding whether the views match but does not give a way of defining a way of mapping the information. This can cause issues at a later date when new functionality is added later and makes backwards compatibility more complicated as you will need to insert things where you're not looking for data. Another possibility is to never move resources but this leads to a non-intuitive resource table.

When the two sides are running different code images they still...