jmg at funkthat.com
Wed Jan 19 21:56:46 UTC 2011
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:
> 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
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
More information about the freebsd-arch