Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 Nov 2015 20:42:01 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        "Conrad E. Meyer" <cem@freebsd.org>
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
Message-ID:  <20151107182254.O1020@besplex.bde.org>
In-Reply-To: <201511070143.tA71h13k038232@repo.freebsd.org>
References:  <201511070143.tA71h13k038232@repo.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151107182254.O1020>