Date: Fri, 21 Jan 2011 12:40:24 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: mdf@freebsd.org, Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= <des@des.no> Subject: Re: Automagic SYSCTLs Message-ID: <201101211240.24571.jhb@freebsd.org> In-Reply-To: <AANLkTinMuQGmNmP2v-GkypqxqprBjcZKZ5y2%2BbU6TAQe@mail.gmail.com> References: <AANLkTi=cbdS0g370r=X%2B=uSd0vsRdC0oRkugq-nsBpgy@mail.gmail.com> <86hbd2bgyw.fsf@ds4.des.no> <AANLkTinMuQGmNmP2v-GkypqxqprBjcZKZ5y2%2BbU6TAQe@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, January 21, 2011 12:04:28 pm mdf@freebsd.org wrote: > 2011/1/21 Dag-Erling Sm=F8rgrav <des@des.no>: > > mdf@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) >=20 > 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). >=20 > > - does this break the ABI? (I hope it does not) >=20 > 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. >=20 > 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= =20 I'd rather get an overflowed counter in my 32-bit app in that case than no= =20 counter at all, esp. since the 32-bit app may know that the counter can wra= p=20 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() does= n't=20 actually handle arrays, it only handles a single long. Anything that uses = an=20 array of longs (such as cp_time[]) has to use a SYSCTL_PROC() handler and t= hat=20 will just have to use the SCTL_32 flag (or whatever it is called) just like= it=20 does now to handle 32-bit compat. =2D-=20 John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201101211240.24571.jhb>