*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->IRIX man pages -> hwgraph (4)              


hwgraph(4)							    hwgraph(4)

NAME    [Toc]    [Back]

     hwgraph, hwgfs, hw	- hardware graph and hardware graph file system

Internal Hardware Graph    [Toc]    [Back]

     Internally, Irix system software maintains	a directed graph called	the
     "hardware graph". The hwgraph represents the collection of	all
     significant hardware connected to a system.  It represents	each piece of
     hardware -- modules, CPUs,	memories, disk controllers, disk drives, disk
     partitions, serial	ports, ethernet	ports, some system integrated
     circuits, etc. -- as a distinct vertex in the graph.   There are some
     additional	vertices that represent	collections of hardware	(e.g. "the
     disks") or	more abstract architectural concepts (e.g. "a node").  The
     contents of the hardware graph are	obviously system-dependent; but	there
     are many common elements that cross system	types.

     Labeled edges are used to connect graph vertexes in a way that shows some
     relationship between the underlying hardware.  For	instance, an edge
     labeled "3" originates at a vertex	that represents	the collection of all
     partitions	on a drive.  It	points to a vertex that	represents the third
     partition on that drive.  Another example:	An edge	labeled	"memory"
     hanging off a vertex that represents a system node	points to a vertex
     that represents the memory	on that	node.

     The internal hwgraph also supports	arbitrarily-labeled information
     associated	with each vertex.  This	allows device drivers to associate
     useful data structures and	other information with a particular device.

     The hardware graph	is maintained by system	software with the cooperation
     of	device drivers using new device	driver interfaces as described in the
     Device Driver Programmer's	Guide.

Hardware graph filesystem (hwgfs)    [Toc]    [Back]

     The internal hardware graph is exported to	user-level through a pseudofile
 system (similar to /proc(4)).	 The hwgfs file	system represents the
     collection	of all interesting hardware and	pseudo-devices as a file
     system tree of special files and directories. It is mounted at /hw	by the
     kernel during system boot,	and can	be re-mounted using /etc/mnthwgfs.  In
     order to represent	the directed graph as a	Unix file system tree, hwgfs
     imposes an	artificial hierarchy on	the hardware graph, and	it uses	hard
     links and symlinks	to represent graph edges that are outside that
     hierarchy.	 Note that it is usually the case that the hwgfs file system
     contains symlinks that point back "up" to higher-level directories. The
     implication is that there will be some symlinks under /hw that form
     cycles which "ls -R" and other commands that recursively descend from a
     directory have trouble dealing with.  Note, however, that the "find"
     command handles symlinks very well	and works as desired:

	  find /hw -print | xargs ls -ld

     hwgfs does	not allow users	to create or remove files or symlinks under
     /hw.  Rather, this	section	of the file system hierarchy is	controlled
     exclusively by device drivers and other system software.  In other	words,

									Page 1

hwgraph(4)							    hwgraph(4)

     /hw should	be viewed purely as a reflection of the	contents of the
     internal hardware graph. The contents of the graph	and the	links within
     it	may change across releases, and	should not be depended upon.  They may
     also change when new hardware releases.

     The internal hardware graph is updated dynamically	when hardware is added
     and removed, and the file system reflection of that graph is updated
     accordingly.  For instance, when the fx(1m) utility is used to
     repartition a disk	drive, the special files used for the old partitioning
     automatically disappear and new special files that	represent the new
     partitioning automatically	appear.

     Since hwgfs is a pseudo-filesystem	whose files don't actually use any
     disk space, there is no persistent	information associated with files
     under /hw.	 In particular,	file attributes	(mode, owner, group) are not
     stored across reboots under hwgfs.	 Rather, reasonable default are	used
     for all hwgfs special files.  These defaults can be changed in the	normal
     ways (i.e.	with chmod(1), chown(1), chgrp(1)), but	the changes only last
     until the next time the system is rebooted.  In order to supply the
     appearance	of special file	attributes that	are persistent across reboots,
     hwgfs uses	the ioconfig(1m) utility, controlled by	the contents of	the
     file /etc/ioperms.

     The /dev directory	is the root of the recommended path for	all device
     file usage, even though many of the files and directories under /dev are
     now symlinks into /hw.

     For example, device names under /hw should	not be used when mounting
     filesystems, or configuring the root filesystem for the kernel.  Only a
     few administrative	programs need to use the hardware graph	pathnames
     under /hw to obtain additional info directly from the hardware graph.

     System software (i.e. device drivers) may associate "labeled information"
     with a hwgraph vertex.  In	particular, lboot(1m) provides the ability to
     associate administrative information with an instance of a	device using
     DEVICE_ADMIN directives.  Such information	is interpreted by the
     appropriate device	driver.	 Additionally, system software (i.e. device
     drivers) may choose to "export" such labeled information to user mode.
     When this is done,	the information	is available as	an extended user-level
     attribute on the hwgfs file that represents that vertex; so it can	be
     obtained with an attr_get(2) call.

Major/Minor Numbers
     As	in earlier releases, the system	uses a 32-bit identifier known as a
     dev_t to identify a particular instance of	a device (or special file).
     In	previous releases, a dev_t consisted of	a "major number" -- which told
     the system	which driver to	use -- and a "minor number" which was a	magic
     cookie interpreted	by that	driver.	 Frequently a minor number was sliced
     into various bit-fields, including	a "unit	number"	which the device
     driver used to index into an array	of per-unit data structures.  For
     backwards compatibility, the Irix kernel continues	to support this	model
     for pseudo-drivers.

									Page 2

hwgraph(4)							    hwgraph(4)

     For hwgraph-aware drivers,	things are a bit different:  A 32-bit dev_t
     still uniquely identifies a device; but the major number is always	0
     (regardless of which driver owns the special file)	and the	minor number
     is	a system-wide unique "vertex handle".  From the	vertex handle, system
     software uses system-level	hwgraph	interfaces to determine	exactly	which
     instance of a device is referenced.  The impact at	user level is that
     there is no way for user code to interpret	minor numbers of a hwgraphaware
 device driver.  The driver writer may provide a library (DSO) with
     appropriate formal	interfaces for user-level operations, or the driver
     writer can	export useful information which	the user can retrieve with

     Note that the dev_t (major/minor) for a particular	device may change
     across reboots.  In general, user code should not attempt to interpret
     the bits in a dev_t, nor is there a valid reason to store a dev_t on
     persistent	storage	for use	across reboots.

Internal hwgraph Interfaces    [Toc]    [Back]

     There is an extensive set of interfaces that allow	device drivers and
     other system software to manipulate the hardware graph.

     Basic operations on vertices include:
	  create, destroy, clone, and get_next.

     Basic operations on edges include:
	  add, remove, and get_next.

     Basic operations on labeled vertex	information include:
	  add, remove, replace,	get, get_next, export, and unexport.

     There are many other operations, too.  These are all defined in the
     Device Driver Programmer's	Guide.

User-level Interfaces    [Toc]    [Back]

     At	user-level, users continue to see special files	which represent
     hardware devices.	Users can create symlinks from normal file systems
     that point	into the hwgfs file system.

     The usual device driver operations	(open, close, read, write, ioctl,
     etc.) and the usual file operations (stat,	attr_get, etc.)	work as
     expected.	As mentioned earlier, chmod, chown, and	chgrp work, but	only
     until the next reboot.  For persistent changes to hwgfs special files,
     the user must use ioconfig(1m).  (This may	change in a future release of

     The ls(1) command includes	an 'S' option that can be used to display the
     canonical device name for a specified hwgfs file or directory.  A
     canonical device name is a	path starting with /hw that unambiguously
     identifies	a device or collection of devices.

									Page 3

hwgraph(4)							    hwgraph(4)

SEE ALSO    [Toc]    [Back]

     attr_get(2), fx(1m), ioconfig(1m),	lboot(1m), ls(1), MAKEDEV(1m),
     setdevperms(1m), linkstat(1), nstats(1), sn(1), xbstat(1m).

									PPPPaaaaggggeeee 4444
[ Back ]
 Similar pages
Name OS Title
wss OpenBSD Windows Sound System hardware driver
pss OpenBSD Personal Sound System hardware driver
softpower HP-UX determine if softpower hardware is installed on the system
hwmgr_view Tru64 Displays information about the status of the system and its hardware components
VkMeter IRIX Display a layered bar graph
tsort NetBSD topological sort of a directed graph
tsort OpenBSD topological sort of a directed graph
SgGraph IRIX An OSF/Motif-compatible graph widget.
gview IRIX graph viewer for Inventor 3d databases
graph Linux 2D graph for plotting X-Y coordinate data.
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service