From owner-svn-src-head@freebsd.org Sat Nov 7 09:42:12 2015 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C023A26F83; Sat, 7 Nov 2015 09:42:12 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 4C9F414C8; Sat, 7 Nov 2015 09:42:12 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id EA9FED45112; Sat, 7 Nov 2015 20:42:01 +1100 (AEDT) Date: Sat, 7 Nov 2015 20:42:01 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "Conrad E. Meyer" cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r290475 - in head: share/man/man9 sys/kern sys/sys In-Reply-To: <201511070143.tA71h13k038232@repo.freebsd.org> Message-ID: <20151107182254.O1020@besplex.bde.org> References: <201511070143.tA71h13k038232@repo.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=cK4dyQqN c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=kj9zAlcOel0A:10 a=1bltlNy1fvD_v7oC0FsA:9 a=CjuIK1q_8ugA:10 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 09:42:12 -0000 On Sat, 7 Nov 2015, Conrad E. Meyer wrote: > Log: > Round out SYSCTL macros to the full set of fixed-width types > > Add S8, S16, S32, and U32 types; add SYSCTL*() macros for them, as well > as for the existing 64-bit types. (While SYSCTL*QUAD and UQUAD macros > already exist, they do not take the same sort of 'val' parameter that > the other macros do.) Actually, the *QUAD macros do take a 'val' parameter (that didn't work), except for the dynamic _ADD forms. SYSCTL_ADD_INT() also takes this parameter. It works there, but is even less useful than for SYSCTL_INT() (it is always possibly to point to a variable). SYSCTL_ADD_LONG() is most inconsistent. It could take a 'val' parameter that would work like for SYSCTL_ADD_INT(), but is like SYSCTL_ADD_QUAD() and doesn't. > Clean up the documented "types" in the sysctl.9 document. (These are > macros and thus not real types, but the manual page documents intent.) > > The sysctl_add_oid(9) arg2 has been bumped from intptr_t to intmax_t to > accommodate 64-bit types on 32-bit pointer architectures. This arg is handled poorly in many places. This is a large ABI change. arg2 is rarely used for scalar sysctls so its use for 64-bit types should be disallowed for all cases instead of fixed or allowed for more cases. Support for 'val' was already left out for the ADD*QUAD macros, perhaps because stronger type checking in these macros made its brokenness more obvious. This arg is not very useful, but was made available at essentially no cost to save a few bytes. Its cost was negative since there was a spare variable in the oid struct that could be repurposed without too many type hacks (it should really be void *, but was intptr_t to represent both void * and small integers). Now its costs are thousands of bytes on 32-bit systems by expanding all oid structs, and larger type hacks. I can't actually find any use of arg2 for a pointer. In most cases where it is really needed, it is a small integer giving a size. sysctl_handle_opaque() is such a case. > This is just the kernel support piece; the userspace sysctl(1) support > will follow in a later patch. You mean sysctl(8). There is also sysctl(3). Both have type info, with too much duplication and too many abstract types in sysctl(3) where the raw C types are of interest. The lists of sysctls in sysctl(3) and sysctl(8) are almost useless since they are so incomplete, but they are in a nicer format than other lists. Bruce