Re: Updated ec-burst.diff patch

From: M. Warner Losh <imp_at_bsdimp.com>
Date: Thu, 03 Jul 2003 15:25:12 -0600 (MDT)
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
           read-only.
	2) Things that can be set in boot process, but also changed
           later.
	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.

Warner
Received on Thu Jul 03 2003 - 12:25:24 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:13 UTC