Date: Tue, 28 Apr 2015 17:01:10 +0800 (PHT)
From: Paul Goyette <paul%vps1.whooppee.com@localhost>
Well, it really is a (pseudo-)device, and even has its own major device
number.
We cannot avoid all of the device goop, since a non-built-in-module
would still have to merge in the devsw. My goal is to eventually be
able to build and run a kernel which has no portion of sysmon built-in,
and still be able to load and unload the wdog/power/envsys components,
along with the actual drivers for timers/power-switches/sensors.
But what purpose does attaching an *autoconf* device serve?
The devsw is the userland interface, /dev/sysmon, and is not actually
related to autoconf devices. You can attach a devsw without any
associated autoconf device, and vice versa.
The defpseudo config directive with the associated (often empty)
xyzattach routine allows you to include or exclude the code from a
kernel statically with the pseudo-device directive.
Some pseudo-devices have multiple instances, e.g. cgd(4): each
/dev/cgdN needs its own separate state. So it uses multiple autoconf
devices to manage the numbered instances. Some pseudo-devices attach
children, so they also need an autoconf device.
In the case of sysmon, there's only one global state. Some of it is
put into a softc struct (sc_minor_mtx); the rest of it is in global
variables (sysmon_opvec_table, sysmon_refcnt). It doesn't seem to
attach any children. There's no defpseudo, so you can't configure it
statically in your kernel.
I think you could remove the whole cfattach/cfdriver/sysmon_match/&c.
business and replace it by initialization in MODULE_CMD_INIT (plus the
RUN_ONCE nonsense because builtin modules get initialized too late).