Browse Prior Art Database

System Resource Attribute Sets and Attribute Set Extensions

IP.com Disclosure Number: IPCOM000033026D
Original Publication Date: 2004-Nov-22
Included in the Prior Art Database: 2004-Nov-22
Document File: 2 page(s) / 75K

Publishing Venue

IBM

Abstract

Operating Systems and Application software often have requirements for the notion of a named resource, along with a set of one or more characteristics or attributes associated with the resource -- for example, a disk device with a name like disk1 with attributes such as hardware address, the name of a specialized software "device driver" needed to access the device, or the name of a "parent" resource upon which access to the device depends. In the simplest cases, there is a fixed set of defined attributes for each unique type of resource (e.g. address, driver, parent), and for each instance of the resource, a set of specific assigned values for those attributes (e.g. 0001, mydriver1, control_unit1) which are conceptually stored together as a "resource profile" record in a file or database and accessed via a "search key" equal to the resource name. Increasingly, however, a given resource type does not have a fixed set of attributes, but multiple -- sometimes overlapping, sometimes mutually exclusive -- attributes that render the simple "resource profile" construct confusing in concept and inefficient in implementation because it might require the superset of all possible attributes. Attribute Sets and Attribute Set Extensions build upon the basic notion that a resource of a given type may have a set of characteristics or attributes associated with it (an "attribute set"), but that one or more of the attributes in this set may in fact identify yet another attribute set -- an "extension" to the base set, with potentially a different set of defined attributes in each unique attribute set extension. This is conceptually easier to understand than the "superset" approach described above, and may be more efficient in both space utilization to store the attribute information and in program access to that information.

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

Page 1 of 2

System Resource Attribute Sets and Attribute Set Extensions

Consider the example of a type of device that may have multiple physical I/O "paths" to it, as well as be supported by more than one software "extension" to the base device driver for the purpose of managing these "paths" using one or more user-specifiable algorithms. Some characteristics or "attributes" of the device (such as its hardware I/O address and the name of the "path control software" extension itself) may be required by all device drivers or by the operating system. In addition, there may be one or more attributes associated with each path to the device, as well as attributes that apply to all paths. Note again that the number, names, and possible values for these "additional" attributes may depend on the specific path control extension software being used.

As a simplified specific example, take 2 devices (DISK1 and DISK2), each with 2 available paths and for which 2 different path control extension software components are available -- "PCMDEF" and "PCMXYZ" -- the "default" one that comes with the operating system and another one with different function that is supplied by the device manufacturer "XYZ". The extension software has the following characteristics: The default PCMDEF supports 2 algorithms -- "failover" (one path will be used for all I/O unless it fails, in which case the other path will be used) and "round robin" (I/O will be routed alternatively to each path). Furthermore, if the failover algorithm is chosen, one path must be designated the "primary" path and the other "secondary".

The manufacturer-suppled PCMXYZ also supports 2 algorithms -- "failover" (same definition as above, but no allowable path designation of "primary" or "secondary"), and "R/W bias" with allowable path-specific values of "READ", "WRITE" or "NONE".

Without attribute set extensions, the "resource profile" for a single disk might have to allow for the possibility (and perhaps storage space) for all possible attributes associated with all possible path control extension software components.

By using attribute set extensions, the "resource profiles" for DISK1 and DISK 2 might look like the following:

DISK1's attribute definitions:

SKEY=DISK1 /* DISK1 is the "search key" naming the device' s attribute set */

     ADDR=0001 /* ADDR is an attribute of the device itself */ DRIVER=diskdrvr1.dll /* name of the base device driver (same for both disks) */

     P...