Change to sysctl to support linux kobj

[Peter Wemm]

On Thu, Aug 5, 2010 at 2:46 PM, Jeff Roberson <jroberson at jroberson.net> wrote:
> Hi folks,
>
> I really need two pointer arguments to a sysctl function to support linux
> sysfs via sysctl.  To facilitate this I propose changing the int arg2 to a
> uinptr_t.  This keeps it as an integer type but makes it wide enough to
> accept a pointer.  A small number of places in the kernel have to be fixed
> for the new type or because they don't use SYSCTL_HANDLER_ARGS.  This will
> introduce an api/abi incompatibility although it is relatively minor.
>
> Comments?  Alternatives?
>
> Thanks,
> Jeff
>
> Index: sysctl.h
> ===================================================================
> --- sysctl.h    (revision 207767)
> +++ sysctl.h    (working copy)
> @@ -114,8 +114,8 @@
>  #define CTL_AUTO_START 0x100
>
>  #ifdef _KERNEL
> -#define SYSCTL_HANDLER_ARGS struct sysctl_oid *oidp, void *arg1, int arg2,
> \
> -       struct sysctl_req *req
> +#define SYSCTL_HANDLER_ARGS struct sysctl_oid *oidp, void *arg1,       \
> +       uintptr_t arg2, struct sysctl_req *req
>
>  /* definitions for sysctl_req 'lock' member */
>  #define REQ_UNLOCKED   0       /* not locked and not wired */
> @@ -158,7 +158,7 @@
>        int             oid_number;
>        u_int           oid_kind;
>        void            *oid_arg1;
> -       int             oid_arg2;
> +       uintptr_t       oid_arg2;
>        const char      *oid_name;
>        int             (*oid_handler)(SYSCTL_HANDLER_ARGS);
>        const char      *oid_fmt;
>
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>

My initial thoughts..  32 bit systems should be unaffected.

Impact on 64 bit systems may be low..  For the args passing on amd64,
that should be covered by the already 64 bit register passing.

The impact on sysctl_oid struct is varied.  It won't change the size
on 64 bit systems because of native alignment requirements adding
invisible padding in the structure already.  A 64 bit type, followed
by 32 bit, followed by 64 bit, leaves space to expand the 32 bit to a
64 bit object.

However, little vs big endian is affected to a different degree.  Big
endian ppc64 would be affected since the oid_arg2 fields won't be in
the same bit positions.  The impact on little endian systems depends
on what goes into the padding area.  If it is usually initialized to
zeroes, we might get away with it.

-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell