Login or Register to Ask a Question and Join Our Community

Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

kudzu(1) [redhat man page]

kudzu(1)						      General Commands Manual							  kudzu(1)

NAME

       kudzu - detects and configures new and/or changed hardware on a system

SYNOPSIS

       kudzu

DESCRIPTION

       kudzu  detects  and  configures	new  and/or changed hardware on a system.  When started, kudzu detects the current hardware, and checks it
       against a database stored in /etc/sysconfig/hwconf, if one exists. It then determines if any hardware has been added or	removed  from  the
       system.	If  so,  it gives the users the opportunity to configure any added hardware, and unconfigure any removed hardware. It then updates
       the database in /etc/sysconfig/hwconf.

       If no previous database exists, kudzu attempts to determine what devices have already been configured,  by  looking  at	/etc/modules.conf,
       /etc/sysconfig/network-scripts/, and /etc/X11/XF86Config.

OPTIONS

       --usage
	      Show short usage message.

       --help, -?
	      Print help information.

       -q, --quiet
	      Run 'quietly'; do only configuration that doesn't require user input.

       -s, --safe
	      Do  only	'safe'	probes that won't disturb hardware. Currently, this disables the serial probe, the DDC monitor probe, and the PS/2
	      probe.

       -t, --timeout [seconds]
	      This sets the timeout for the initial dialog. If no key is pressed  before  the  timeout	elapses,  kudzu  exits,  and  /etc/syscon-
	      fig/hwconf is not updated.

       -k, --kernel [version]
	      When  determining  whether a module exists, use the specified kernel version. (If this is not set, it defaults to the current kernel
	      version.) Do not specify suffixes such as 'smp' or 'summit'; these are automatically searched.

       -b, --bus [bus]
	      Only probe on the specified bus.

       -c, --class [class]
	      Only probe for the specified class.

       -f, --file [file]
	      Read hardware probe info from file file and do not do an actual probe.

       -p, --probe
	      Print probe information to the screen, and do not actually configure or unconfigure any devices.

FILES

       /etc/sysconfig/hwconf
	      Listing of current installed hardware.

       /etc/sysconfig/kudzu
	      Configuration for the boot-time hardware probe. Set 'SAFE' to something other than 'no' to force only safe probes.

       /etc/modules.conf
	      Module configuration file.

       /etc/sysconfig/network-scripts/ifcfg-*
	      Network interface configuration files.

       BUGS   The serial probe will disturb any currently in-use devices, and returns odd results if used on machines acting as  serial  consoles.
	      On some older graphics cards, the DDC probe can do strange things.

AUTHOR

       Red Hat, Inc.

4th Berkeley Distribution					   Red Hat, Inc.							  kudzu(1)

Check Out this Related Man Page

probe(9E)							Driver Entry Points							 probe(9E)

NAME

       probe - determine if a non-self-identifying device is present

SYNOPSIS

       #include <sys/conf.h>
       #include <sys/ddi.h>
       #include <sys/sunddi.h>

       static intprefixprobe(dev_info_t *dip);

INTERFACE LEVEL

       Solaris DDI specific (Solaris DDI). This entry point is required for non-self-identifying devices.  You must write it for such devices. For
       self-identifying devices,  nulldev(9F) should be specified in the dev_ops(9S) structure if a probe routine is not necessary.

ARGUMENTS

       dip     Pointer to the device's	dev_info structure.

DESCRIPTION

       probe() determines whether the device corresponding to dip actually exists and is a valid device for this driver. probe() is  called  after
       identify(9E)  and  before  attach(9E) for a given dip. For example, the probe() routine can map the device registers using ddi_map_regs(9F)
       then attempt to access the hardware using ddi_peek(9F) or ddi_poke(9F) and determine if the  device  exists.   Then  the  device  registers
       should be unmapped using ddi_unmap_regs(9F).

       To  probe a device that was left powered off after the last detach(), it might be necessary to power it up. If so, the driver must power up
       the device by accessing device registers directly. pm_raise_power(9F) will be not be available until attach(9E). The framework ensures that
       the  ancestors  of  the	node  being  probed and all relevant platform-specific power management hardware is at full power at the time that
       probe() is called.

       probe() should only probe the device. It should not change any software state and should not create any software state. Device  initializa-
       tion should be done in attach(9E).

       For a self-identifying device, this entry point is not necessary. However, if a device exists in both self-identifying and non-self-identi-
       fying forms, a  probe() routine can be provided to simplify the driver. ddi_dev_is_sid(9F) can then be used to determine  whether   probe()
       needs to do any work. See ddi_dev_is_sid(9F) for an example.

RETURN VALUES

       DDI_PROBE_SUCCESS      If the probe was successful.

       DDI_PROBE_FAILURE      If the probe failed.

       DDI_PROBE_DONTCARE     If the probe was unsuccessful, yet attach(9E) should still be called.

       DDI_PROBE_PARTIAL      If the instance is not present now, but may be present in the future.

SEE ALSO

       attach(9E), identify(9E), ddi_dev_is_sid(9F), ddi_map_regs(9F), ddi_peek(9F), ddi_poke(9F), nulldev(9F), dev_ops(9S)

       Writing Device Drivers

SunOS 5.11							    18 Nov 1992 							 probe(9E)
Man Page