config_rootsearch man page on MirBSD

Man page or keyword search:  
man Server   6113 pages
apropos Keyword Search (all sections)
Output format
MirBSD logo
[printable version]

AUTOCONF(9)		      BSD Kernel Manual			   AUTOCONF(9)

NAME
     autoconf - autoconfiguration framework

SYNOPSIS
     #include <sys/param.h>
     #include <sys/device.h>

DESCRIPTION
     Autoconfiguration is the process of matching hardware devices with an ap-
     propriate device driver. In its most basic form, autoconfiguration con-
     sists of the recursive process of finding and attaching all devices on a
     bus, including other busses.

     The autoconfiguration framework supports direct configuration where the
     bus driver can determine the devices present.

     The autoconfiguration framework also supports indirect configuration
     where the drivers must probe the bus looking for the presence of a dev-
     ice. Direct configuration is preferred since it can find hardware regard-
     less of the presence of proper drivers.

     The autoconfiguration process occurs at system bootstrap and is driven by
     a table generated from a "machine description" file by config(8). For a
     description of the config(8) "device definition" language, see
     files.conf(5).

     Each device must have a name consisting of an alphanumeric string that
     ends with a unit number. The unit number identifies an instance of the
     driver. Device data structures are allocated dynamically during autocon-
     figuration, giving a unique address for each instance.

INITIALIZATION
     void
     config_init(void);

     The config_init() function initializes the autoconfiguration data struc-
     tures.

INDIRECT CONFIGURATION
     void *
     config_search(cfmatch_t func, struct device *parent, void *aux);

     void *
     config_rootsearch(cfmatch_t func, char *rootname, void *aux);

     The config_search() function performs indirect configuration of physical
     devices by iterating over all potential children, calling the given func-
     tion func for each one.

     The config_rootsearch() function finds the root device identified by the
     string rootname, in a manner similar to config_search(), except that
     there is no parent device. If func is NULL, config_search() applies each
     child's match function instead. The argument parent is the pointer to the
     parent's device structure. The given aux argument describes the device
     that has been found and is simply passed on through func to the child.
     config_search() returns a pointer to the best-matched child or NULL oth-
     erwise.

     The role of func is to call the match function for each device and call
     config_attach() for any positive matches.

     typedef int (*cfmatch_t)(struct device *parent, void *child, void *aux);

     If func is NULL, then the parent should record the return value from
     config_search() and call config_attach() itself.

     Note that this function is designed so that it can be used to apply an
     arbitrary function to all potential children. In this case callers may
     choose to ignore the return value.

DIRECT CONFIGURATION
     struct device *
     config_found_sm(struct device *parent, void *aux, cfprint_t print,
	     cfmatch_t submatch);

     struct device *
     config_found(struct device *parent, void *aux, cfprint_t print);

     struct device *
     config_rootfound(char *rootname, void *aux);

     The config_found_sm() function performs direct configuration on a physi-
     cal device. config_found_sm() is called by the parent and in turn calls
     the submatch function to call the match function as determined by the
     configuration table. If submatch is NULL, the driver match functions are
     called directly. The argument parent is the pointer to the parent's dev-
     ice structure. The given aux argument describes the device that has been
     found. The softc structure for the matched device will be allocated, and
     the appropriate driver attach function will be called.

     If the device is matched, the system prints the name of the child and
     parent devices, and then calls the print function to produce additional
     information if desired. If no driver takes a match, the same print func-
     tion is called to complain. The print function is called with the aux ar-
     gument and, if the matches failed, the full name (including unit number)
     of the parent device, otherwise NULL.

     typedef int (*cfprint_t)(void *aux, const char *parentname);
     #define QUIET   0		     /* print nothing */
     #define UNCONF  1		     /* print " not configured" */
     #define UNSUPP  2		     /* print " not supported" */

     Two special strings, "not configured" and "unsupported" will be appended
     automatically to non-driver reports if the return value is UNCONF or
     UNSUPP respectively, otherwise the function should return the value
     QUIET.

     The config_found_sm() function returns a pointer to the attached device's
     softc structure if the device is attached, NULL otherwise. Most callers
     can ignore this value, since the system will already have printed a diag-
     nostic.

     The config_found() macro expands to config_found_sm(parent, aux, print,
     submatch) with submatch set to NULL and is provided for compatibility
     with older drivers.

     The config_rootfound() function performs the same operation on the root
     device identified by the rootname string.

ATTACHING AND DETACHING DEVICES
     struct device *
     config_attach(struct device *parent, void *cf, void *aux,
	     cfprint_t print);

     int
     config_detach(struct device *dev, int flags);

     The config_attach() function attaches a found device. Memory is allocated
     for the softc structure and the driver's attach function is called ac-
     cording to the configuration table. If successful, config_attach() re-
     turns the softc. If unsuccessful, it returns NULL.

     The config_detach() function is called by the parent to detach the child
     device. The second argument flags contains detachment flags:

     #define DETACH_FORCE    0x01    /* Force detachment; hardware gone */
     #define DETACH_QUIET    0x02    /* Don't print a notice */

     The config_detach() function returns zero if successful and an error code
     otherwise. config_detach() is always called from process context, allow-
     ing sleep(9) to be called while the device detaches itself (to deal with
     processes which have a device open).

DEVICE ACTIVATION/DEACTIVATION
     int
     config_activate(struct device *dev);

     int
     config_deactivate(struct device *dev);

     The config_activate() function is called by the parent to activate the
     child device dev. It is called to activate resources and initialise other
     kernel subsystems (such as the network subsystem). config_activate() is
     called from interrupt context after the device has been attached.

     The config_deactivate() function is called by the parent to deactivate
     the child device dev. config_deactivate() is called from interrupt con-
     text to immediately relinquish resources and notify dependent kernel sub-
     systems that the device is about to be detached. At some later point,
     config_detach() will be called to finalise the removal of the device.

DEFERRED CONFIGURATION
     void
     config_defer(struct device *dev, void (*func)(struct device *));

     The config_defer() function is called by the child to defer the remainder
     of its configuration until all its parent's devices have been attached.
     At this point, the function func is called with the argument dev.

CODE REFERENCES
     The autoconfiguration framework itself is implemented within the file
     sys/kern/subr_autoconf.c. Data structures and function prototypes for the
     framework are located in sys/sys/device.h.

SEE ALSO
     autoconf(4), files.conf(5), config(8)

HISTORY
     Autoconfiguration first appeared in 4.1BSD. The autoconfiguration frame-
     work was completely revised in 4.4BSD. The detach and activate/deactivate
     interfaces appeared in NetBSD 1.5.

MirOS BSD #10-current	       August 25, 2002				     2
[top]

List of man pages available for MirBSD

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net