Weed-whacking sysctl(8)

John Baldwin jhb at freebsd.org
Wed Jan 19 20:59:48 UTC 2011


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.

> 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)?

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'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.

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.

-- 
John Baldwin


More information about the freebsd-arch mailing list