Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/dev/sysmon



   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).


Home | Main Index | Thread Index | Old Index