DEVD.CONF(5) FreeBSD File Formats Manual DEVD.CONF(5)
NAME
devd.conf - configuration file format for devd(8)
DESCRIPTION
General Syntax
A devd(8) configuration consists of two general features, statements and
comments. All statements end with a semicolon. Many statements can
contain substatements, which are also terminated with a semicolon.
The following statements are supported:
attach Specifies various matching criteria and actions to perform when
a newly attached device matches said criteria.
detach Specifies various matching criteria and actions to perform when
a newly detached device matches said criteria.
nomatch Specifies various matching criteria and actions to perform when
no device driver currently loaded in the kernel claims a (new)
device.
notify Specifies various matching criteria and actions to perform when
the kernel sends an event notification to userland.
options Specifies various options and parameters for the operation of
devd(8).
Statements may occur in any order in the configuration file, and may be
repeated as often as required. Further details on the syntax and meaning
of each statement and their substatements are explained below.
Each statement, except options has a priority (an arbitrary number)
associated with it, where `0' is defined as the lowest priority. If two
statements match the same event, only the action of the statement with
highest priority will be executed. In this way generic statements can be
overridden for devices or notifications that require special attention.
The general syntax of a statement is:
statement priority {
substatement "value";
...
substatement "value";
};
Sub-statements
The following sub-statements are supported within the options statement.
directory "/some/path";
Adds the given directory to the list of directories from which
devd(8) will read all files named "*.conf" as further
configuration files. Any number of directory statements can
be used.
pid-file "/var/run/devd.pid";
Specifies PID file.
set regexp-name "(some|regexp)";
Creates a regular expression and assigns it to the variable
regexp-name. The variable is available throughout the rest of
the configuration file. If the string begins with `!', it
matches if the regular expression formed by the rest of the
string does not match. All regular expressions have an
implicit `^$' around them.
The following sub-statements are supported within the attach and detach
statements.
action "command";
Command to execute upon a successful match. Example
"/etc/pccard_ether $device-name start".
class "string";
This is shorthand for "match "class" "string"".
device-name "string";
This is shorthand for "match "device-name" "string"". This
matches a device named string, which is allowed to be a
regular expression or a variable previously created containing
a regular expression. The "device-name" variable is available
for later use with the action statement.
match "variable" "value";
Matches the content of value against variable; the content of
value may be a regular expression. Not required during attach
nor detach events since the device-name statement takes care
of all device matching. For a partial list of variables, see
below.
media-type "string";
For network devices, media-type will match devices that have
the given media type. Valid media types are: "Ethernet",
"802.11", and "ATM".
subdevice "string";
This is shorthand for "match "subdevice" "string"".
The following sub-statements are supported within the nomatch statement.
action "command";
Same as above.
match "variable" "value";
Matches the content of value against variable; the content of
value may be a regular expression. For a partial list of
variables, see below.
The following sub-statements are supported within the notify statement.
The "notify" variable is available inside this statement and contains, a
value, depending on which system and subsystem that delivered the event.
action "command";
Command to execute upon a successful match. Example
"/etc/rc.d/power_profile $notify".
match "system | subsystem | type | notify" "value";
Any number of match statements can exist within a notify
statement; value can be either a fixed string or a regular
expression. Below is a list of available systems, subsystems,
and types.
media-type "string";
See above.
Variables that can be used with the match statement
A partial list of variables and their possible values that can be used
together with the match statement. The variables are published by the
bus based on characteristics of the device that generated the event (for
device events). Variables for other classes of events are dependent on
those events.
Variable Description
* The entire message from the current event.
_ The entire message from the current event, after the
initial type character.
timestamp The time this event was processed, in seconds since 1970
dot fraction.
bus Device name of parent bus.
cdev Device node path if one is created by the devfs(4)
filesystem.
class Device class.
comm Executable name (kernel).
core Path to core file (kernel).
device Device ID.
devclass Device Class (USB).
devsubclass Device Sub-class (USB).
device-name Name of attached/detached device.
endpoints Endpoint count (USB).
function Card functions.
interface Interface ID (USB).
intclass Interface Class (USB).
intprotocol Interface Protocol (USB).
intsubclass Interface Sub-class (USB).
jail Jail name for the process triggering the rule (RCTL).
mode Peripheral mode (USB).
notify Match the value of the "notify" variable.
parent Parent device.
pid PID of the process triggering the rule (RCTL).
port Hub port number (USB).
product Product ID (USB).
release Hardware revision (USB).
ruid Real UID of the process triggering the rule (RCTL).
rule Rule (RCTL).
sernum Serial Number (USB).
slot Card slot.
subvendor Sub-vendor ID (PCI).
subdevice Sub-device ID (PCI).
subsystem Matches a subsystem of a system, see below.
system Matches a system type, see below.
type Type of notification, see below.
vendor Vendor ID.
Notify matching
A partial list of systems, subsystems, and types used within the notify
mechanism.
System Subsystem Type Description
ACPI Events related to the ACPI Subsystem.
ACPI ACAD AC line state ($notify=0x00 is
offline, 0x01 is online).
ACPI Button Button state ($notify=0x00 is power,
0x01 is sleep).
ACPI CMBAT Battery events.
ACPI Dock Dock state ($notify=0x00 is undocked,
0x01 is docked).
ACPI Lid Lid state ($notify=0x00 is closed,
0x01 is open).
ACPI PROCESSOR Processor state/configuration
($notify=0x81 is a change in available
Cx states).
ACPI Resume Resume notification.
ACPI Suspend Suspend notification.
ACPI Thermal Thermal zone events.
System Subsystem Type Description
AEON power press The power button on an Amiga has been
pressed.
System Subsystem Type Description
CAM Events related to the cam(4) system.
CAM periph Events related to peripheral devices.
CAM periph error Generic errors.
CAM periph timeout Command timeouts.
System Subsystem Type Description
CARP Events related to the carp(4)
protocol.
CARP vhid@inet The "subsystem" contains the actual
CARP vhid and the name of the network
interface on which the event took
place.
CARP vhid@inet MASTER Node become the master for a virtual
host.
CARP vhid@inet BACKUP Node become the backup for a virtual
host.
System Subsystem Type Description
coretemp Events related to the coretemp(4)
device.
coretemp Thermal Notification that the CPU core
has reached critical temperature.
coretemp Thermal temperature String containing the temperature
of the core that has become too
hot.
System Subsystem Type Description
DEVFS
DEVFS CDEV CREATE The devfs(4) node is created.
DEVFS CDEV DESTROY The devfs(4) node is destroyed.
System Subsystem Type Description
ETHERNET inet IFATTACH Notification when the default VNET
instance of the inet interface is
attached.
System Subsystem Type Description
GEOM Events related to the
geom(4) framework. The
difference compared to
DEVFS is that GEOM only
includes disk-like devices.
GEOM DEV CREATE A geom(4) provider is
created.
GEOM DEV DESTROY A geom(4) provider is
destroyed.
GEOM DEV GEOM::physpath The physical path of a
device has changed.
GEOM DEV GEOM::rotation_rate The rotation rate of the
disk has changed.
GEOM DEV MEDIACHANGE Physical media has changed.
GEOM DEV SIZECHANGE A geom(4) provider size has
changed.
System Subsystem Type Description
IFNET
IFNET inet The "subsystem" is the actual name of
the network interface on which the
event took place.
IFNET inet LINK_UP Carrier status changed to UP.
IFNET inet LINK_DOWN Carrier status changed to DOWN.
IFNET inet ATTACH The network interface is attached to
the system.
IFNET inet DETACH The network interface is detached
from the system.
IFNET inet RENAME The network interface is renamed.
IFNET inet ADDR_ADD The network interface address added.
IFNET inet ADDR_DEL The network interface address
removed.
System Subsystem Type Description
kernel signal coredump Notification that a process has
crashed and dumped core.
kernel power resume Notification that the system has woken
from the suspended state.
System Subsystem Type Description
nvme controller Controller events provide the
controller name (for example,
nvme0) in $name.
nvme controller SMART_ERROR A SMART Critical Warning State
change has happened. $state has a
hex bitmask of the bits that
changed, as defined in the NVMe
Standard for Critical Warning field
of log page 2 "SMART / Health
Information Log":
Bit Value Meaning
0x1 Spare capacity below
threshold
0x2 Temperature outside
acceptable range
0x4 Reliability of media
degraded
0x8 Media placed into read-
only mode
0x10 Volatime memory backup
failure
0x20 Persistent memory read-
only or degraded
nvme controller RESET A controller reset event has
happened. $event is one of
"start", "success", and "timed_out"
representing the start of a
controller reset, the successful
completion of a controller reset,
or a timeout while waiting for the
controller to reset, respectively.
nvme controller RECONNECT An NVMe over Fabrics host has
disconnected and is requesting a
reconnect.
System Subsystem Type Description
PMU Notification of events from
various types of Power
Management Units.
PMU AC Notifications of AC power
related events.
PMU AC overvoltage An over-voltage condition
was detected on the AC power
line.
PMU AC plugged Power has been applied to
the AC power line.
PMU AC unplugged Power has been removed from
the AC power line.
PMU Battery
PMU Battery absent Battery is no longer absent.
PMU Battery charged The battery has become
charged.
PMU Battery charging The battery has started
charging.
PMU Battery disconnected The battery has been
disconnected.
PMU Battery high-temp The battery reported a
temperature over the limit.
PMU Battery low-temp The battery reported a
temperature under the limit.
PMU Battery plugged The battery has become
plugged (eg connected).
PMU Battery shutdown-threshold The power in the battery has
fallen below the shutdown
threshold.
PMU Battery warning-threshold The power in the battery has
fallen below the warn the
user threshold.
PMU Button pressed A button on a adb(4) or
pmu(4) has been pressed.
PMU keys One of the keys on the
adb(4) keyboard has been
pressed.
PMU keys brightness A brightness level change
has been requested.
Direction is in the $notify
variable.
PMU keys mute The mute key
PMU keys volume A volume level change has
been requested. Direction
is in the $notify variable.
PMU keys eject An ejection has been
requested.
PMU lid close The pmc(4) device has
detected the lid closing.
PMU lid open The pmc(4) device has
detected the lid openinging.
PMU POWER ACLINE The pmc(4) device has
detected an AC line state
($notify=0x00 is offline,
0x01 is online).
PMU USB overvoltage An over-voltage condition on
the power lines for the USB
power pins.
PMU USB plugged A device has been plugged
into a USB device.
PMU USB undervoltage An under-voltage condition
on the power lines for the
USB power pins.
PMU USB unplugged A device has been unplugged
from a USB device.
System Subsystem Type Description
RCTL Events related to the rctl(8)
framework.
RCTL rule matched A rule with action specified as
"devctl" was triggered.
System Subsystem Type Description
USB Events related to the USB subsystem.
USB DEVICE ATTACH USB device is attached to the system.
USB DEVICE DETACH USB device is detached to the system.
USB INTERFACE ATTACH USB interface is attached to a device.
USB INTERFACE DETACH USB interface is detached from a
device.
System Subsystem Type Description
VFS Events from the vfs system.
VFS FS Events that change what is mounted to
the system.
VFS FS MOUNT Notification of a filesystem is
mounted for the first time.
VFS FS REMOUNT Notification of a filesystem is
remounted (whether or not the options
actually change).
VFS FS UNMOUNT Notification of a filesystem being
unmounted.
System Subsystem Type Description
VT BELL RING Notification that the console bell has
rung. See vt(4) for details.
System Subsystem Type Description
ZFS ZFS Events about the ZFS subsystem. See
zfsd(8) and /etc/devd/zfs.conf for
details.
System Subsystem Type Description
SND Events related to the sound(4) driver.
SND CONN IN Connected input device specified in
cdev variable.
SND CONN OUT Connected output device specified in
cdev variable.
SND CONN NODEV No connected devices.
A link state change to UP on the interface "fxp0" would result in the
following notify event:
system=IFNET subsystem=fxp0 type=LINK_UP
An AC line state change to "offline" would result in the following event:
system=ACPI subsystem=ACAD notify=0x00
Comments
Comments may appear anywhere that whitespace may appear in a
configuration file. To appeal to programmers of all kinds, they can be
written in C, C++, or shell/Perl constructs.
C-style comments start with the two characters `/*' (slash, star) and end
with `*/' (star, slash). Because they are completely delimited with
these characters, they can be used to comment only a portion of a line or
to span multiple lines.
C-style comments cannot be nested. For example, the following is not
valid because the entire comment ends with the first `*/':
/* This is the start of a comment.
This is still part of the comment.
/* This is an incorrect attempt at nesting a comment. */
This is no longer in any comment. */
C++-style comments start with the two characters `//' (slash, slash) and
continue to the end of the physical line. They cannot be continued
across multiple physical lines; to have one logical comment span multiple
lines, each line must use the `//' pair. For example:
// This is the start of a comment. The next line
// is a new comment, even though it is logically
// part of the previous comment.
Notes on Variable Expansion
Variables are expanded by preceding them by a "$" sign. Any text
immediately following that sign, starting with a letter, a minus sign
"-", an underscore "_", or an asterisk "*" is considered an internal
variable, and expanded accordingly. If that variable does not exist, it
silently expands to an empty string. Consequently, if the intention is
to pass a sh(1) variable, it must be surrounded by braces to prevent it
from being considered an internal variable.
See EXAMPLES for a detailed example.
To prevent issues with special shell characters, the following happens
for each variable $foo.
1. The characters "$'" are inserted.
2. The string "$foo" is removed.
3. The value of the foo variable is inserted into the buffer with all
single quote characters prefixed by a backslash.
4. A final "'" is inserted.
See sh(1) for what this construct means. It is safe in all context,
except one: inside single quotes. If foo=meta and bar=var, then a rule
like the following:
action "echo '$foo $bar'";
will be presented to the shell via system(3) as
echo '$'meta' $'var''
which produces the following output:
$meta $var
as its output. This is an unanticipated result. A future version of
this software will change this behavior. Users are discouraged from
using single quotes inside action value without due care.
The above should be written as
action "echo $foo' '$bar"
to produce a single argument to echo. Given the above expansion,
juxtaposing bare variables with single quote expressions will produce the
right output, regardless of the value of the variable.
FILES
/etc/devd.conf The devd(8) configuration file.
/etc/devd A directory that devd searches for additional
configuration files.
/usr/local/etc/devd
A directory that devd searches for additional
configuration files.
EXAMPLES
#
# This will catch link down events on the interfaces fxp0 and ath0
#
notify 0 {
match "system" "IFNET";
match "subsystem" "(fxp0|ath0)";
match "type" "LINK_DOWN";
action "logger $subsystem is DOWN";
};
#
# Match lid open/close events
# These can be combined to a single event, by passing the
# value of $notify to the external script.
#
notify 0 {
match "system" "ACPI";
match "subsystem" "Lid";
match "notify" "0x00";
action "logger Lid closed, we can sleep now!";
};
notify 0 {
match "system" "ACPI";
match "subsystem" "Lid";
match "notify" "0x01";
action "logger Lid opened, the sleeper must awaken!";
};
#
# Match a USB device type
#
notify 0 {
match "system" "USB";
match "subsystem" "INTERFACE";
match "type" "ATTACH";
match "intclass" "0x0e";
action "logger USB video device attached";
};
#
# Try to configure ath and iwn devices with pccard_ether
# as they are attached.
#
attach 0 {
device-name "(ath|iwn)[0-9]+";
action "/etc/pccard_ether $device-name start";
};
#
# Stop ath and iwn devices as they are detached from
# the system.
#
detach 0 {
device-name "(ath|iwn)[0-9]+";
action "/etc/pccard_ether $device-name stop";
};
The following example illustrates the difference between internal and
shell variables:
attach 20 {
device-name "umodem[0-9]+";
match "vendor" "0x2047";
match "product" "0x001(0|3|4)";
match "interface" "0";
action "cd /dev; p=$product; dn=$device-name; \
un=$(sysctl -n dev.umodem.${dn#umodem}.ttyname); \
chmod 666 cua${un}; ln -sf cua${un} mspfet${p#0x}";
};
"product", and "device-name" are internal variables. Their contents are
initially assigned to shell variables "p", and "dn", respectively. Then,
variable "dn" is used inside a shell command substitution, assigning to
shell variable "un". Finally, this shell variable is used in two other
shell statements, where it needs to be wrapped in braces in order to
prevent it from being considered in internal variable to devd.
The installed /etc/devd.conf has many additional examples.
SEE ALSO
cam(4), coretemp(4), devfs(4), re_format(7), devd(8)
BUGS
The variable expansion's interaction with single quotes is suboptimal and
surprising.
FreeBSD 15.1-STABLE-HBSD February 26, 2026 DEVD.CONF(5)