From owner-freebsd-arch@FreeBSD.ORG Fri Jan 21 17:04:30 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 9957A1065672 for ; Fri, 21 Jan 2011 17:04:30 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5D8958FC0C for ; Fri, 21 Jan 2011 17:04:30 +0000 (UTC) Received: by iwn39 with SMTP id 39so1899673iwn.13 for ; Fri, 21 Jan 2011 09:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MzNDMHu3CJ4PKJZulkpuMLe/NhIkGWHESZi4kjyBNRY=; b=gGriEQQUH4dpvEIix6RxNXu2tHjKHWRm2aVKrn+wxuHO1fXrRs0WFjZrj9gbPMSqrf sx279YThqOVQwu4K6EkdK/QY1guXLapPuiaDvZ2/TbgWVede3z2h6ditpkSYr81Wco7d yj47ZGF1WlL0Q94JoVCVuhQCY9pUUdg0KJSwY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ijPp3ojW+AMHNXiEllEM4vrEkymQkUfZkRVf2gE92Xn//MMKdg05OPWrZIbCL4oNlV LkVz5K7D0Yi/MgKngKWPXV1zFBMZqhc91d2d/kh3xw6AMEUWuLYQKqzsyNdW+5xKVyih ix0X4sStNjzIPV9L7QgOXiakZeutDIvztvABg= MIME-Version: 1.0 Received: by 10.231.16.132 with SMTP id o4mr1024724iba.154.1295629468329; Fri, 21 Jan 2011 09:04:28 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.231.160.147 with HTTP; Fri, 21 Jan 2011 09:04:28 -0800 (PST) In-Reply-To: <86hbd2bgyw.fsf@ds4.des.no> References: <86hbd2bgyw.fsf@ds4.des.no> Date: Fri, 21 Jan 2011 09:04:28 -0800 X-Google-Sender-Auth: viwb_ixBUQLevAT83DS_zebfCjM Message-ID: From: mdf@FreeBSD.org To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Arch 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:04:30 -0000 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. =A0For the case of a long, there's >> some goop for SCTL_MASK32. =A0For the case of 8 and 16 bit variables, >> they are still copied in and out as 32-bit quantities. > > The inevitable question: > > =A0- does this break the KBI? =A0(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). > =A0- does this break the ABI? =A0(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