Updated ec-burst.diff patch

M. Warner Losh imp at bsdimp.com
Thu Jul 3 14:25:25 PDT 2003

In message: <20030703102627.D92002 at root.org>
            Nate Lawson <nate at root.org> writes:
: On Thu, 3 Jul 2003, M. Warner Losh wrote:
: > In message: <20030701164231.M88547 at root.org>
: >             Nate Lawson <nate at root.org> writes:
: > : On Wed, 2 Jul 2003, Florian Smeets wrote:
: > : > I set hw.acpi.ec.burst_mode=0 in loader.conf but when i was trying to
: > : > chek if it was set to 0 with sysctl hw.acpi.ec.burst_mode i got :
: > : >
: > : > flo at lappi [~] 15 #sysctl hw.acpi.ec.burst_mode
: > : > sysctl: unknown oid 'hw.acpi.ec.burst_mode'
: > :
: > : It's a tunable, not a sysctl.  So you can only set it in loader.conf.  Are
: > : there any messages when you boot with that in your loader.conf?  Would you
: > : please post a separate dmesg for that case?
: >
: > I personally think that all tunable should be read-only (or rw if
: > possible) sysctls...
: I'm still not sure why we have both mechanisms.  Perhaps a useful approach
: would be to sweep the tree for tunables and change them to sysctls with
: appropriate permissions (read-only if in doubt).  Then remove the tunable
: mechanism.  Care to put together a patch?

We have both mechanisms because there are a number of things in sysctl
that just do not make sense to be a tunable.  For example, the number
of packets transmitted, or the memory usage string aren't good for
this.  We have three classes here:

	1) things that must be set early in boot sequence and are then
	2) Things that can be set in boot process, but also changed
	3) Things that are initialized to the same value all the time,
           and only changed from time to time based on events
           happening in the system.

Tunables are #1.  tunables + sysctl are number 2 (although there are a
large number of sysctls that could be tunables but aren't for
historical reasons).  Sysctl for #3 make up the vast bulk of things.

So it wouldn't quite so easy to do...  However, if you can deal with
these, then it might not be a bad idea.


More information about the freebsd-current mailing list