1.2 Media Manager

The Media Manager is comprised of two components: the foundation and the default set of classes. Other classes can be developed and added to MM, on the fly, to increase value to the I/O system but these additional classes would be considered extensions to MM.

This section covers the following topics:

1.2.1 Foundation

The Media Manager foundation is the component upon which all other I/O services are built. It is comprised of the core, the application interface, and the class interface, as illustrated the following figure.

Figure 1-2 The Media Manager foundation

1.2.2 Application Interface

The application interface is the top level interface through which applications discover, manage, and communicate with objects of the I/O system and through which I/O requests are submitted. See Reference for a complete list of the API set.

1.2.3 Media Manager Core

Media Manager core is a database of arbitrary objects instantiated by applications, object managers, and I/O subsystems. All objects in the database appear to the core as a generic object. The generic object has a name, an ID, an owner/creator, and an entry point, as well as a number of other common elements. The core also posts a variety of notifications indicating object state changes.

1.2.4 Class Interface

The class interface is used by an application to extend the Media Manager foundation by registering a class with the Media Manager. The class defines the behavior and instance variables of the objects instantiated from it. Classes abstract the generic object into more useful and well defined objects such as I/O objects or application objects. For an illustration of the class interface and some of its default classes, see Media Manager Classes.

Every object in the database is ultimately created by the class responsible for it. Each class has the know how to effectively communicate with and control objects belonging to that class. Object associations are also established by applications according to class policies.

The details of creating classes and of maintaining objects is beyond the scope of this document. Nevertheless, an understanding of some of the default classes is essential for users of the application interface.

1.2.5 Media Manager Classes

This section introduces all of the default classes of the Media Manager. However, only those classes that are useful to users of the application interface will be discussed in detail.

The default classes in the Media Manager are as follows:

Section 3.2, Attribute Class

Section 3.9, Notify Class

Section 3.1, Application Class

Section 3.11, Reservation Class

Section 3.10, Object Manager Class

Section 3.6, IO Class

Section 3.7, IO Subsystem Class

Section 3.8, Message Class

Section 3.4, Filter Class

Section 3.5, Identifier Class

 

 

Figure 1-3 shows the default classes and their objects as they relate to the class interface.

Figure 1-3 Media Manager Default Classes

Objects are instantiated using the API MM_RegisterObject. Parameters of the API identify the class from which an object is be instantiated, and a structure possessing the information required by the class to create the object. This structure is, in essence, a registration form. The Classes chapter introduces those structures of interest to applications.

1.2.6 Object IDs (OBIDs)

Object IDs (OBIDs), uniquely identify an object in the Media Manager database. OBIDs, or pointers to OBIDs, are required by most of the Media Manager APIs. OBIDs are not static, that is to say, an OBID value identifying a particular object in the database is not likely to be the same value across server initializations. Nor is it guaranteed to be the same during server up time.

For instance, suppose the OBID value for a Device object were 0x1F. Should that device’s driver be unloaded, the device object would be unregistered from the Media Manager database. When the driver is reloaded and the device object is re-instantiated in the database, its OBID might not be the value 0x1F as it had been previously. Should another I/O object be registered with the database before the driver is loaded, it might acquire the previously used value 0x1F. Applications that remember OBIDs for an extended length of time and do not register for object unregistration events are likely to run into difficulties by making bad assumptions about the remembered OBIDs.

1.2.7 Object Handles (HNLDs)

Object handles (HNDLs) are a special case OBID and can be used wherever an OBID is required. The possessor of a HNDL is the owner of an object. A HNDL is returned to the application registering an object, for instance, when an application registers itself, an attribute, a notify event, etc. All applications can discover objects in the Media Manager database and collect information about those objects by using OBIDs, but to unregister an object requires a HNDL, implying that only the owner of an object can unregister the object. Like OBIDs, HNDLs are not static across server down times; however, unlike the OBID, it is not likely that a HNDL’s value will be reused during server up time.