Date: Tue, 28 Apr 2015 17:01:10 +0800 (PHT) From: Paul Goyette <p...@vps1.whooppee.com>
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).