From owner-freebsd-arch@FreeBSD.ORG Fri Jan 21 17:44:36 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A107106566C; Fri, 21 Jan 2011 17:44:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E82168FC15; Fri, 21 Jan 2011 17:44:35 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 52F5D46B0C; Fri, 21 Jan 2011 12:44:35 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5C4638A009; Fri, 21 Jan 2011 12:44:32 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Fri, 21 Jan 2011 12:40:24 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <86hbd2bgyw.fsf@ds4.des.no> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201101211240.24571.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 21 Jan 2011 12:44:32 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: mdf@freebsd.org, Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= Subject: Re: Automagic SYSCTLs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 17:44:36 -0000 On Friday, January 21, 2011 12:04:28 pm mdf@freebsd.org wrote: > 2011/1/21 Dag-Erling Sm=F8rgrav : > > 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