ioconfig(4) [hpux man page]

ioconfig(4)						     Kernel Interfaces Manual						       ioconfig(4)

NAME

       ioconfig - ioconfig entry format

SYNOPSIS

DESCRIPTION

       The file is used to retain information on a system's I/O configuration across reboots.  It contains two types of information:

	 o  Mappings of dynamically allocated major numbers to drivers.

	 o  Mappings of instance numbers to hardware paths.

       At  boot  time this file is read and the information is stored in the kernel data structure.  The file is created by at install time and is
       modified by and when devices are added or removed (see insf(1M), rmsf(1M), and ioscan(1M)).  The only purpose of the file to maintain  con-
       figuration  information	when  the system is not running.  While the system is running, all accesses are made directly to the kernel struc-
       ture, although any tools that change the kernel structures must also keep consistent.

       There will be two copies of maintained: and A second copy is placed in because NFS diskless clients are not guaranteed to have  a  reliable
       directory at boot time.

       The file begins with the magic number.

       Following the magic number is an array of structures, which logically form a tree structure defining the connectivity of the various levels
       of software modules and managers, the device class and hardware address of each element, and the logical unit  associated  with	each  leaf
       node.  The root of the tree is array element 0.

       Each contains the following fields as defined in

       The definitions of each element are as follows:

       Each record must have a character string as its first entry
		 which	is  used to identify the record type.  The default record is the If the string begins with an underscore character then it
		 is one of the variants.

       This is the default record entry for the ioconfig file.
		 The must begin with an underscore character to distinguish record from other record type.

       The element is a structure that contains following elements.

       This record stores information about major numbers dynamically assigned
		 to drivers.  It is used to allow major number assignments to persist across boots.  The must begin with (underscore) character to
		 distinguish record from other record type.

       The contains following elements.

AUTHOR

       was developed by HP.

FILES

       SEE ALSO
	      insf(1M), ioinit(1M), ioscan(1M), rmsf(1M), magic(4).

																       ioconfig(4)

DEVCTL(4)						   BSD Kernel Interfaces Manual 						 DEVCTL(4)

NAME

     devctl -- device event reporting and device control interface

DESCRIPTION

     The devctl device is used to report device events from the kernel.  Future versions will allow for some device control as well.

IMPLEMENTATION NOTES

     This design allows only one reader for /dev/devctl.  This is not desirable in the long run, but will get a lot of hair out of this implemen-
     tation.  Maybe we should make this device a clonable device.

     Also note: we specifically do not attach a device to the device_t tree to avoid potential chicken and egg problems.  One could argue that all
     of this belongs to the root node.	One could also further argue that the sysctl(3) interface that we have now might more properly be an
     ioctl(2) interface.

     SIGIO support is included in the driver.  However, the author is not sure that the SIGIO support is done correctly.  It was copied from a
     driver that had SIGIO support that likely has not been tested since FreeBSD 3.4 or FreeBSD 2.2.8!

     The read channel for this device is used to report changes to userland in realtime.  We return one record at a time.  If you try to read this
     device a character at a time, you will lose the rest of the data.	Listening programs are expected to cope.

     The sysctl and boot parameter hw.bus.devctl_disable is used to disable devctl when no devd(8) is running.

PROTOCOL

     The devctl device uses an ASCII protocol.	The driver returns one record at a time to its readers.  Each record is terminated with a newline.
     The first character of the record is the event type.

     Type    Description
     !	     A notify event, such as a link state change.
     +	     Device node in tree attached.
     -	     Device node in tree detached.
     ?	     Unknown device detected.

   Message Formats
     Except for the first character in the record, attach and detach messages have the same format.

	   Tdev at parent on location

     Part	 Description
     T		 + or -
     dev	 The device name that was attached/detached.
     parent	 The device name of the parent bus that attached the device.
     location	 Bus specific location information.

     The nomatch messages can be used to load devices driver.  If you load a device driver, then one of two things can happen.	If the device
     driver attaches to something, you will get a device attached message.  If it does not, then nothing will happen.

     The attach and detach messages arrive after the event.  This means one cannot use the attach message to load an alternate driver.	The attach
     message driver has already claimed this device.  One cannot use the detach messages to flush data to the device.  The device is already gone.

SEE ALSO

     devd(8)

BSD
								 February 11, 2003							       BSD