Naming the Public Module and Data Store Containers

The public module and containers must both contain version numbers to enable the architecture's upgrading mechanism to work.

Public Module Name

You must use the following name format for your public module:

ds_name.so.ver

where name is the name of the module and ver is the container format version number. The name must use a prefix that is an internationally known identifier associated with your organization. For example, the public modules that Sun Microsystems provides have names prefixed with SUNW, the stock ticker symbol for Sun. For example, the NIS+ public module is named ds_SUNWnisplus.so.1. By including such an identifier in the module name, you avoid public module name collisions in the /usr/lib/inet/dhcp/svc public module directory.

If your company name is Inet DataBase, for example, you might call your module ds_IDBtrees.so.1

Container Name

The container names presented to the administrator through the administrative interface must always be dhcptab and the dotted IP network address for the DHCP network tables, such as 10.0.0.0.

Internally, the data store container names must contain the version number to enable you to produce revisions of your container formats whenever necessary. This naming scheme allows the coexistence of multiple versions of a container, which is a requirement for the architecture's container version upgrade mechanism to work.

The names used for the containers should include a globally recognizable token to ensure that the names are unique.

For example, the NIS+ public module provided with Solaris DHCP would create the dhcptab container internally as SUNWnisplus1_dhcptab. The container for the 172.21.174.0 network table would be SUNWnisplus1_172.21.174.0.

If your company name is Inet DataBase, and your public module is ds_IDBtrees.so.1, you would name your containers IDBtrees1_dhcptab and IDBtrees1_172.21.174.0.