AIX supports name resolution from five different maps:
With the Dynamic Load Application Programming Interface (API) you can load your own modules to provide routines that supplement the maps provided by AIX. The Dynamic Load API enables you to create dynamically loading APIs in any of five map classes: hosts, services, protocols, networks, and netgroup. You can build your own user modules containing APIs for any or all of the map classes. The following sections define an API's function names and prototypes for each of the five classes. See Configuring a Dynamic API for information about configuring a dynamically loading API with AIX.
AIX supports five map classes for user-loadable modules: services, protocols, hosts, networks and netgroup. To instantiate each map accesssor, AIX requires that a user provided module must use the following AIX specified function names and function prototypes for each map class.
The following is the required prototype for a user-defined services map class:
void *sv_pvtinit(); void sv_close(void *private); struct servent * sv_byname(void *private, const char *name, const char *proto); struct servent * sv_byport(void *private, int port, const char *proto); struct servent * sv_next(void *private); void sv_rewind(void *private); void sv_minimize(void *private);
Function sv_pvtinit is always required, though it is not required to return anything more than NULL (that is, the function can do nothing more than return NULL if the calling routine does not need private data), but the routine must exist.
Functions other than sv_pvtinit in a user-defined module for services map class are optional. It is permissible for a user to provide none or only part of the optional functions definition.
The following is the required prototype for a user-defined protocols map class:
void * pr_pvtinit(); void pr_close(void *private); struct protoent * pr_byname(void *private, const char *name); struct protoent * pr_bynumber(void *private, int num); struct protoent * pr_next(void *private); void pr_rewind(void *private); void pr_minimize(void *private);
Function pr_pvtinit is always required. The user-defined modules need not return anything more than NULL (that is, the function can do nothing more than return NULL if the calling routine does not need private data), but the routine must exist.
Functions other than pr_pvtinit in the user module for the protocols map class are optional. It is permissible for a user to provide none or only part of the optional functions definition.
The following is the required prototype for a user-defined hosts map class:
void * ho_pvtinit(); void ho_close(void *private); struct hostent * ho_byname(void *private, const char *name); struct hostent * ho_byname2(void *private, const char *name, int af); struct hostent * ho_byaddr(void *private, const void *addr, size_t len, int af); struct hostent * ho_next(void *private); void ho_rewind(void *private); void ho_minimize(void *private);
Function ho_pvtinit is always required. The user-defined function is not required to return anything more than NULL (that is, the function can do nothing more than return NULL if the calling routine does not need private data), but the routine must exist.
Functions other than ho_pvtinit in the user-defined module for hosts map class are optional. It is permissible for a user to provide none or only part of the optional functions definition.
The following is the required prototype for a user-defined networks map class:
void * nw_pvtinit(); void nw_close(void *private); struct nwent * nw_byname(void *private, const char *name, int addrtype); struct nwent * nw_byaddr(void *private, void *net, int length, int addrtype); struct nwent * nw_next(void *private); void nw_rewind(void *private); void nw_minimize(void *private);
Function nw_pvtinit is always required. The function is not required to return anything more than NULL (that is, the function can do nothing more than return NULL if the calling routine does not need private data), but the routine must exist.
Functions other than nw_pvtinit in the user module for the networks map class are optional. It is permissible for a user to provide none or part of the optional functions definition.
AIX provides a data structure required to implement the networks map class, which uses this structure to communicate with the operating system.
struct nwent {
char *name; /* official name of net */
char **n_aliases; /* alias list */
int n_addrtype; /* net address type */
void *n_addr; /* network address */
int n_length; /* address length, in bits */
};
The following is the required prototype for a user-defined netgroup map class:
void * ng_pvtinit(); void ng_rewind(void *private, const char *group); void ng_close(void *private); int ng_next(void *private, char **host, char **user, char **domain); int ng_test(void *private, const char *name, const char *host, const char *user, const char *domain); void ng_minimize(void *private);
Function ng_pvtinit is always required. The user is not required to return anything more than NULL (that is, the function can do nothing more than return NULL if the calling routine does not need private data), but the routine must exist.
Functions other than ng_pvtinit in the user module for the netgroup map class are optional. It is permissible for a user to provide none or part of the optional functions definition.
You need to name your user-defined module according to a pre-established convention, and you also need to configure it into the operating system before it will work. The following sections explain API module naming and configuration.
The names of modules containing user-defined APIs follow this general form:
NameAddressfamily
where Name is the name of the dynamic loadable module name. The length of the Name can be between one to eight characters.
The following key words are reserved as the user option name and may not be used as the name of the dynamically loadable module:
Addressfamily, which represents the address family, can be either 4 or 6. If no number is specified, address family is AF_UNSPEC. If the number is 4, address family is AF_INET. If the number is 6, address family is AF_INET6.
Any other format for user options is not valid.
If user called gethostbyname2 system call in the application, whatever the address family the user passed to the gethostbyname2 system call will overwrite the address family in the user option. (for example, we have a user option david6, in the application, there is a system call gethostbyname2(name, AF_INET). Then the address family AF_INET will overwrite the user option's address family (6, same as AF_INET6).
There are three ways that a user can specify user-provided, dynamically loading resolver routines:
export NSORDER=local, bind, bob, nis, david4, jason6
In this example, AIX will invoke the listed name resolution modules left to right until the name is resolved. The modules named local, bind, and nis are reserved by AIX:, but bob, david4, and jason6 are user-provided modules.
hosts=nis, jason4, david, local, bob6, bind
hosts dns continue hosts jason6 merge hosts david4
The maximum number of user modules a user can specify from any one of the above source is 16.
Environment variable NSORDER has the highest priority, next is configuration file /etc/netsve.conf , the configuration file /etc/irs.conf has the lowest priority. If there is a user option specified in a higher priority source (for example, NSORDER), then any other user options specified in the lower priority sources (for example, /etc/netsvc.conf and /etc/irs.conf) will be ignored.
To create and install a module containing a dynamically loading API, follow these steps: