Weed-whacking sysctl(8)

[mdf at FreeBSD.org]

On Wed, Jan 19, 2011 at 1:43 PM, John-Mark Gurney <jmg at funkthat.com> wrote:
> mdf at freebsd.org wrote this message on Wed, Jan 19, 2011 at 12:28 -0800:
>> 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.
>> 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)?
>
> I've been watching this discussion pretty closely as I recently wrote
> a bsnmp module to export sysctl values and ran into the problem of
> parsing data exactly how sysctl(8) does it for presentation.
>
> What about creating a new SYSCTL_KELVIN that is SYSCTL_PROC that
> converts that variable in kelvin into 10ths of Kelvin, or as a
> floating point value?
>
> It would break people who were directly parsing sysctl(3) output, but
> they were also never quering the type via the undocumented API to get
> the correct format and type information in the first place and depending
> upon the undocumented type behavior.
>
> The man pages for acpi_thermal(4), amdtemp(4) and coretemp(4) only
> say that the temp is supplied by those sysctl nodes, not the format
> nor that they are in the magic 10ths of Kelvin formation.  So only
> preserving sysctl(8) output would be my vote.  (Preserving sysctl(3)
> users that properly understands format and/or type would also be best).
>
> I was about to write a patch to add a function to libc to be able to
> get both format string and type, but obviously this has changed a bit
> in the last week, and at least the format string part will not be
> necessary.

IMO it would be nice to have a real API to fetch the type.  The sysctl
documentation claims it's being thought about, but I think it's said
that for several years. :-)

The format string was mostly unused and I'd prefer it to die than be
used more.  Except for the case of "IK" and 4 specially formatted
structs, the string provides no new information over the ctltype.

Thanks,
matthew