Weed-whacking sysctl(8)

[mdf at FreeBSD.org]

On Wed, Jan 19, 2011 at 12:54 PM, Alfred Perlstein <alfred at freebsd.org> wrote:
> * mdf at FreeBSD.org <mdf at FreeBSD.org> [110119 12:28] 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.
>> 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'd say that it's not great to break either system.
>
> The reason is that either the syscall or cmd line utility can be
> the basis of numerous system monitoring tools.
>
> By breaking either interface we discourage people from using it.
>
> I apologize for coming in so late, but why is CTLTYPE_KELVIN such
> an awful thing?

Mostly because it's relatively unused, and except for three
acpi_thermal instances it's read-only.  I wasn't able to find any
tools in the tree that knew what format these are in, and as someone
else pointed out the units aren't part of any documentation either.

> Also, not to digress, but it sounds like there's a rototilling of
> the KPI going on here as well that might break 3rd parties who do
> their own monitoring software.

So far I don't believe I have changed any KPI except for if someone
had a custom handler for a QUAD.  I would like to do so at some point
as 99% of SYSCTL set-up uses OID_AUTO, and it should be 100% but for
some legacy code.

> Overall it's not a big thing, but when you consider all the changes
> like this that go on, it can add up to a discouraging target to
> track.
>
> Honestly I don't have a strong opinion on this and feel free to use
> your best judgement and as well as what other people bring to the
> table, I just wanted to bring the software churn issue up and
> leave the question, "is there a way to do this with minimal 3rd party
> breakage".

Existing uses of the standard SYSCTL_[ADD_]FOO can be made backwards
compatible for a release or so, with minimal effort on my part.  It
makes the tree a little uglier for a while, though.

I was involved with a FreeBSD merge at $WORK from 6.1 to stable/7 and
there was a decent bit of change in there.  For my part, I preferred a
nice clean compile-break to something that still compiled but wasn't
the right way to do things going forward.

Thanks,
matthew