DEVICE_PROBE(9)

💖 DEVICE_PROBE(9) — probe for device existence 💖

ok so this is a page from the Kernel Developer's Manual, and bestie, if you're writing drivers you're gonna meet this one. it's literally the vibe-check function for hardware. no cap.

---

✨ SYNOPSIS ✨

#include <sys/param.h>
#include <sys/bus.h>

int
DEVICE_PROBE(device_t dev);

like. that's the whole signature. she's simple. she's iconic. 🎀

---

🌸 DESCRIPTION 🌸

okay so DEVICE_PROBE() is the method that goes "hey, is this device actually here??" — it probes for the device's existence. that's the whole job.

and it returns:

• 0 if the device exists 🫶
• ENXIO if it cannot be found 😭
• some other appropriate error code if something else goes sideways during the probe (a memory allocation failure, for example — rude)

but WAIT, there's more, because sometimes more than one driver matches the same device, and then it turns into a lil competition. in that case you return a priority value. here's the lore:

• success codes are values less than or equal to zero, and the highest value is the best match
• failure codes are positive values, and you should use the regular Unix error codes for that

⚠️ and now the serious part, bestie, listen up: if a driver returns a success code less than zero, it must not assume it's gonna be the same driver that gets attached to the device. in particular, it must not assume that any values stored in the softc structure will be available for its attach method — and any resources allocated during probe must be released and re-allocated if the attach method is called. also it is an absolute requirement that the probe routine have no side effects whatsoever. zero. none. the probe routine may be called more than once before the attach routine is called. so don't be out here leaving mess everywhere 💀

if a success code of zero is returned, then the driver can assume it will be the one attached — but it must not hold any resources when the probe routine returns. a driver may assume that the softc is preserved when it returns a success code of zero. 💅

---

🔥 RETURN VALUES 🔥

• a value equal to or less than zero means success
• a value greater than zero means an error (errno)

for the values equal to or less than zero:

• zero means highest priority, and no further probing is done
• for a value less than zero, the lower the value, the lower the priority — e.g. -100 indicates a lower priority than -50

---

🦋 the convention values (the matching-strength menu) 🦋

these are the values used by convention to indicate different strengths of matching in a probe routine. except as noted, these are just suggested values, and there's nothing magical about them. fr fr, they're vibes, not law.

• BUS_PROBE_SPECIFIC — the device that cannot be reprobed, and that no possible other driver may exist for. typically the legacy drivers who don't follow all the rules, or the special-needs drivers 👑
• BUS_PROBE_VENDOR — the device is supported by a vendor driver. this is for source or binary drivers that are not yet integrated into the FreeBSD tree. > its use in the base OS is prohibited. 🚫
• BUS_PROBE_DEFAULT — the device is a normal device matching some plug and play ID. this is the normal return value for drivers to use, and it is intended that nearly all of the drivers in the tree should return this value. she's the default for a reason bestie 💖
• BUS_PROBE_LOW_PRIORITY — the driver is a legacy driver, or an otherwise less desirable driver for a given plug and play ID. the driver has special requirements, like when there are two drivers that support overlapping series of hardware devices. in that case the one that supports the older part of the line would return this value, while the one that supports the newer ones would return BUS_PROBE_DEFAULT. generational drama, honestly 🎀
• BUS_PROBE_GENERIC — the driver matches the type of device generally. this allows drivers to match all serial ports generally, with specialized drivers matching particular types of serial ports that need special treatment for some reason ✨
• BUS_PROBE_HOOVER — the driver matches all unclaimed devices on a bus. the ugen(4) device is one example. she's hoovering up everything, no crumbs left 🌈
• BUS_PROBE_NOWILDCARD — the driver expects its parent to tell it which children to manage, and no probing is really done. the device only matches if its parent bus specifically said to use this driver. no guessing games, only direct instructions 🫶

---

👀 SEE ALSO 👀

• device(9)
• DEVICE_ATTACH(9)
• DEVICE_DETACH(9)
• DEVICE_IDENTIFY(9)
• DEVICE_SHUTDOWN(9)

---

💜 AUTHORS 💜

this manual page was written by Doug Rabson. ty king 🫡

---

ok that's the whole page, you're basically a kernel dev now, mwah 💋

this came out of the Debian edition, dated February 8, 2012 — yes she's an elder but she still ate and left no crumbs. go probe something responsibly, bestie 🌸🦋✨