Next: Control Operations Up: Utility Routines Previous: Host Name Service

ROM file parsing utilities

When writing a protocol that provides user-configurable ROM file options, one can make use of the ROM file parsing utilities to process the ROM file entries. To use these utilities:

  1. Write separate routines to handle each ROM option your protocol will support. These routines should be of the following type:

    The ROM file parsing code will call this handler when it finds an appropriate line in the ROM file. The number of fields on that line and the fields themselves will be placed in numFields and fields, respectively. The line number is provided to allow the handler to produce error messages if desired.

    If the handler returns XK_FAILURE, the parsing code will print a generic ``ROM file format error'' message, specifying the name of the protocol and the line number.

  2. Create an array of XObjRomOpt structures which bind option names to their handling functions. There is one XObjRomOpt structure for each ROM option.

  3. Somewhere in your protocol's initialization code, call findXObjRomOpts.

    xkern_return_t findXObjRomOpts( XObj, XObjRomOpt *, int numOpts, void * arg );

    This routine scans through the ROM file, looking for lines where the first field matches either the protocol name or the full instance name of the XObject (e.g., if the protocol instance is ethdrv/SE0, ROM file entries with either ethdrv/SE0 or ethdrv would match.) When such a match is found, the array of XObjRomOpts is scanned. If the second field of the line matches the name field of one of the XObjRomOpts, or if the name field of one of the XObjRomOpts is the empty string, the XObjRomOptFunc for that option is called with the object, all ROM fields on that line, the number of fields on that line, the line number and the user-supplied argument.

    If the first field of a ROM line appears to match the XObject but none of the supplied RomOpts matches the second field, an error message will be printed and XK_FAILUREwill be returned. The rest of the ROM entries will not be scanned. This same behavior results from the XObjRomOptFunc returning XK_FAILUREand from a ROM line with too few fields for its associated handler.

As an example, consider a protocol which supports two ROM options, a port option and an mtu option, both of which take single integer parameters. This example shows how this protocol would interface with the romopt parsing utilities:



static xkern_return_t	readMtu( XObj, char **, int, int, void * );
static xkern_return_t	readPort( XObj, char **, int, int, void * );


static XObjRomOpt opts[] = {
    { "mtu", 3, readMtu },
    { "port", 3, readPort }
};


static xkern_return_t 
readMtu( XObj self, char **arr, int nFields, int line, void *arg )
{
    PState	*ps = (PState *)self->state;

    return sscanf (arr[2], "%d", &ps->mtu) < 1  ? XK_FAILURE : XK_SUCCESS;
}

static xkern_return_t 
readPort( XObj self, char **arr, int nFields, int line, void *arg )
{
    PState	*ps = (PState *)self->state;

    return sscanf (arr[2], "%d", &ps->port) < 1  ? XK_FAILURE : XK_SUCCESS;
}



foo_init( XObj self ) 
{
    ...
    findXObjRomOpts(self, opts, sizeof(opts)/sizeof(XObjRomOpt), 0);
    ...
}



Next: Control Operations Up: Utility Routines Previous: Host Name Service


Tue Nov 29 16:28:56 MST 1994