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