Date: Thu, 28 Feb 2008 15:31:27 +0100 From: Marko Zec <zec@icir.org> To: Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?= <des@des.no> Cc: Julian Elischer <julian@elischer.org>, FreeBSD Current <current@freebsd.org> Subject: Re: warning of pending commit attempt. Message-ID: <200802281531.28052.zec@icir.org> In-Reply-To: <86tzjt1ar3.fsf@ds4.des.no> References: <47C39948.3080907@elischer.org> <200802280343.57576.zec@icir.org> <86tzjt1ar3.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 28 February 2008 14:17:04 Dag-Erling Sm=C3=B8rgrav wrote:
> Marko Zec <zec@icir.org> writes:
> > [about vimage]
>
> One thing you haven't mentioned is sysctl. I've always been of the
> opinion that if we virtualize one part of the system, we should also
> virtualize the sysctl tree. This does not mean that each vimage
> should have its own copy of the entire tree, but rather that it
> should be possible to mark some sysctl nodes as virtualized. For
> instance, it would be useful on amd64 to be able to create an i386
> vimage, where hw.machine and hw.machine_arch would be "i386".
>
> For PROC nodes, of course, this is easily done (as you already do)
> with INIT_VPROCG(TD_TO_VPROGC(curthread)), but the basic node types
> (int, long, string etc.) are a little trickier, and don't seem to be
> handled in your patch.
Actually the patch provides certain level of support for virtualizing=20
leaf sysctl nodes. So far I have only introduced macros for methods /=20
data types that I've found necessary to virtualize, such as=20
SYSCTL_V_OID, SYSCTL_V_STRING, SYSCTL_V_INT, and SYSCTL_V_PROC. =20
Instead of embedding a "pointer" to the variable that a sysctl needs to=20
control into the linker set that standard SYSCTL macros create, the=20
SYSCTL_V macros embed an ID of the virtualization container / strucrure=20
where the data has to be resolved, and an offset inside such a=20
structure.
Here's a randomly picked example from a recent diff:
+#ifndef VIMAGE
struct icmpstat icmpstat;
=2DSYSCTL_STRUCT(_net_inet_icmp, ICMPCTL_STATS, stats, CTLFLAG_RW,
=2D &icmpstat, icmpstat, "");
+#endif
+SYSCTL_V_STRUCT(V_NET, vnet_inet, _net_inet_icmp, ICMPCTL_STATS, stats,
+ CTLFLAG_RW, icmpstat, icmpstat, "");
So the latter macro will embedd an offsetof(struct vnet_inet, _icmpstat)=20
somewhere in the resulting linker set structure, with V_NET telling us=20
that we are resolving a networking symbol, and vnet_inet will also be=20
translated to an ID determining in which networking submodule to=20
resolve the address.
The above sysctl will be handled by the sysctl_handle_v_int() function:
#ifdef VIMAGE
int
sysctl_handle_v_int(SYSCTL_HANDLER_V_ARGS)
{
int tmpout, error =3D 0;
SYSCTL_RESOLVE_V_ARG1();
/*
* Attempt to get a coherent snapshot by making a copy of the=20
data.
*/
tmpout =3D *(int *)arg1;
error =3D SYSCTL_OUT(req, &tmpout, sizeof(int));
if (error || !req->newptr)
return (error);
if (!arg1)
error =3D EPERM;
else
error =3D SYSCTL_IN(req, arg1, sizeof(int));
return (error);
}
#endif
Observe the SYSCTL_RESOLVE_V_ARG1() macro above which does the actual=20
magic of computing the address of the target variable:
/*
* Resolve void *arg1 in a proper virtualization container.
*/
#ifdef VIMAGE
#define SYSCTL_RESOLVE_V_ARG1() do {
char *cp;
switch (subs) {
case V_NET:
cp =3D (char *) TD_TO_VNET(curthread)->mod_data[mod];
break;
case V_PROCG:
cp =3D (char *) TD_TO_VPROCG(curthread);
break;
case V_CPU:
cp =3D (char *) TD_TO_VCPU(curthread);
break;
default:
panic("unsupported module id %d", subs);
}
arg1 =3D cp + (size_t) arg1;
} while (0)
#endif
Hmm probably I should make subs and mod the arguments of the above=20
macro...
Anyhow if the kernel is compiled without "options VIMAGE" the SYSCTL_V=20
macros fall back to standard SYSCTL macros of course.
Hope this clarifies the picture to some extent...
Marko
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200802281531.28052.zec>