Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Jul 2008 13:09:49 +0200
From:      Marko Zec <zec@icir.org>
To:        freebsd-virtualization@freebsd.org
Subject:   Re: Simpler Vimage sysctls
Message-ID:  <200807161309.49269.zec@icir.org>
In-Reply-To: <487787CC.6020302@gritton.org>
References:  <487787CC.6020302@gritton.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 11 July 2008 18:18:20 James Gritton wrote:
> While working on combining jail_set and Vimage, I found that the
> sysctl virtualization hacks were more complicated than they needed to
> be.
>
> The extra "subs" and "mod" arguments in SYSCTL_HANDLER_V_ARGS don't
> need to be explicitly passed because they're members of the
> sysctl_v_oid structure passed in the oidp argument.  By using
> oidp->oid_v_subs instead of subs (and same for mod),
> SYSCTL_HANDLER_V_ARGS becomes the same as SYSCTL_HANDLER_ARGS, and no
> longer need to be defined.
>
> With the handlers now taking the same arguments, the sysctl_oid and
> sysctl_v_oid structures become identical and sysctl_v_oid can go
> away.
>
> Unrelated to this is the various SYSCTL_V_XXX macros that refer to
> either SYSCTL_V_OID or SYSCTL_OID depending on the VIMAGE define. 
> Since SYSCTL_V_OID already reduces to SYSCTL_OID if VIMAGE is
> undefined, those further switches are unnecessary.
>
> I'm including a diff that trims all this away, while keeping the same
> functionality.
>
> - Jamie

Good catch, thanks!

I just submitted a slightly modified version of your patch to p4/vimage 
branch, which allows for this to work with both options VIMAGE and 
nooptions VIMAGE configurations -> SYSCTL_V_* macros need to 
automatically fall back to their "plain" SYSCTL_* counterparts for 
nooptions VIMAGE builds.

In retrospect, I really cannot recall why I introduced this 
SYSCTL_HANDLER_V_ARGS special casing in the first place, besides 
perhaps having it as an explicit reminder that in functions acting as 
handlers for virtualized objects, it is required to look up and 
dereference the address of such object in the appropriate resource 
container structure, which can / must be accomplished via 
SYSCTL_RESOLVE_V_ARG1() macro.

Thanks,

Marko



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