Automagic SYSCTLs
John Baldwin
jhb at freebsd.org
Fri Jan 21 17:44:36 UTC 2011
On Friday, January 21, 2011 12:04:28 pm mdf at freebsd.org wrote:
> 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.
I think your approach is better since 64-bit stat counters may overflow and
I'd rather get an overflowed counter in my 32-bit app in that case than no
counter at all, esp. since the 32-bit app may know that the counter can wrap
and handle wrapping internally.
> 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.
The array of longs was my initial main worry, but sysctl_handle_long() doesn't
actually handle arrays, it only handles a single long. Anything that uses an
array of longs (such as cp_time[]) has to use a SYSCTL_PROC() handler and that
will just have to use the SCTL_32 flag (or whatever it is called) just like it
does now to handle 32-bit compat.
--
John Baldwin
More information about the freebsd-arch
mailing list