Weed-whacking sysctl(8)

[Bruce Evans]

On Wed, 19 Jan 2011, John Baldwin wrote:

> On Wednesday, January 19, 2011 3:28:19 pm mdf at freebsd.org wrote:
>> As bde@ mentioned, there's very little actual use of the sysctl format
>> strings.  I recently changed it so the use is even smaller, but I've
>> got a quandary as to how to finish the job.
>>
>> I agree with Bruce that the formatted structs can just be removed.
>
> Hmm, I've actually used 'sysctl kern.clockrate' in the past.

But you would have found it easier to use if its output were

     kern.clockrate.hz: 100
     kern.clockrate.tick: 10000
     kern.clockrate.profhz: 1024
     kern.clockrate.stathz: 128

instead of

     kern.clockrate: { hz = 100, tick = 10000, profhz = 1024, stathz = 128 }

, no?  Even more so for use in a script, say

     hz=$(sysctl -n kern.clockrate.hz)	# can't do this now.

The old clockrate sysctl would be retained for binary compatibility, but
need not have special support in sysctl(8).  The new sysctl would have
to have a different name, but `clockrate' isn't such a good name anyway
(`tick' isn't a rate, but the inverse of a rate, i.e., a time.  However,
it is closely associated with `hz' so it should be in the same sysctl
tree, perhaps kern.clock.)

>> This leaves just the "IK" format, which shows up in just a few files:
>>
>> sys/dev/acpica/acpi_thermal.c:
>> sys/dev/amdtemp/amdtemp.c
>> sys/dev/acpi_support/atk0110.c
>> sys/dev/coretemp/coretemp.c
>> sys/dev/iicbus/max6690.c
>> sys/dev/iicbus/ds1775.c
>>
>> I see two solutions to "IK".  The first is to preserve the interface
>> as experienced by sysctl(8) users, and add some functions to push a
>> string buffer back to userspace, and parse a string in the kernel.
>> The second is to preserve the binary interface as experienced by
>> sysctl(3) users, and either have the values be dumped in the slightly
>> obscure 10ths of Kelvin values, or add a new CTLTYPE_KELVIN so
>> sysctl(8) can also keep showing things as it does today.
>>
>> Given how infrequent the use is CTLTYPE_KELVIN seems a non-starter.
>> So who is the worse client to break: those who use sysctl(8) to look
>> at temperatures, or those who have a utility to manipulate these
>> values using sysctl(3)?

Special formatting for these in sysctl(8) was a mistake, but I think
have a special CTLTYPE to keep indicating that these are temperatures
is very easy, especially since it is used infrequently.

Also, it's not Kelvin, but deci-Kelvin :-).

> So what is sufficiently broken elsewhere that requires us to break the
> existing sysctls?  Many people use the output of sysctl(8) for coretemp, and
> the ACPI thermal zones and breaking that gratuitously would be unfortunate.

I only want to remove the format strings.  This saves checking that they
are consistent with the data types, and some space.

> I've no idea if there is existing code reading these sysctls in userland for
> things like gkrellm, but I wouldn't be surprised if there were.

Hopefully thes is none using the format string except sysctl(8).  sysctl(8)
has to use intentionally still (?) undocumented sysctls even to read the
format string.  Other applications just need to know what sysctls returning
degrees in deci-Kelvin actually are.  They should have no difficulty knowing
that the format is deci-Kelvin.

> Even CTLTYPE_KELVIN would require changes to user apps, but I also would
> rather present an actual number to userland rather than a string so userland
> doesn't have to parse it just to get back to the original number.
>
> I guess I fail to see why sysctl giving a hint about the semantic type of
> the data ("temperature", "struct foo") which is separate from the "physical"
> type (e.g. 32-bit or 64-bit) is such a bad thing.

Note that this is not done for newer sysctls like kern.cp_time and
kern.cptimes.  The latter is especially cryptic since it doesn't even
have delimiters for each CPU.  Please keep them that way :-).  (I have
occasionally used kern.cptime output and had to stare at it to make sense
of it.  Dividing it by stathz would have been only a small help.  I
needed differences of it and ran a filter to get them.)  Converting
deci-Kelvin to Kelvin is relatively trivial.  So is converting to
Centigrade.  But many would prefer Fahrenheit, or a GUI representation...
The fancy presentation belongs in specialized apps.

Bruce