Automagic SYSCTLs

mdf at FreeBSD.org mdf at FreeBSD.org
Fri Jan 21 17:04:30 UTC 2011


2011/1/21 Dag-Erling Smørgrav <des at des.no>:
> mdf at FreeBSD.org writes:
>> The gist is that the handler knows the sizeof the variable in the
>> kernel and uses this to copy out.  For the case of a long, there's
>> some goop for SCTL_MASK32.  For the case of 8 and 16 bit variables,
>> they are still copied in and out as 32-bit quantities.
>
> The inevitable question:
>
>  - does this break the KBI?  (I assume it does, almost inevitably)

It can be made gradual, such as #defining SYSCTL_ADD_INT to use the
new interface (but this only works at the moment with OID_AUTO and I'd
rather not add a nbr parameter to the macro).

>  - does this break the ABI?  (I hope it does not)

Mostly no, but the answer is slightly tricky.  At the moment only
LONG/ULONG has code to manage a read from 32-bit app on 64-bit kernel.
 There is no way to detect at compile time the difference between a
long and an int64_t on a 64-bit build, since one is a typedef of the
other.  So the new handler has to assume any 8-byte quantity *may* be
coming from a long in order to maintain the 32/64 compat code.

Bruce suggested an alternate mechanism, which is to use the size the
app passed in if the data will fit, and ENOMEM otherwise.  This would
in theory affect the ABI but in practice shouldn't do much, except
that today sysctl_handle_long() will truncate the data for a 32-bit
app and my intended new code would only SYSCTL_OUT to a 4-byte
user-space variable when the data fits without loss of information.

The answer is further complicated by the difference between sysctl(8)
and sysctl(3).  sysctl(8) can essentially be made well-behaved, but
it's not clear what people may be doing with sysctl(3).  However, it
is true that, at the moment, it requires a lot of work to push out an
array of longs that are 4/8 bytes on 64-bit kernel depending only on
the bitness of the app, without a specialized handler in the kernel.

This answer probably did not make anything clearer.

Thanks,
matthew


More information about the freebsd-arch mailing list