From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 14:31:38 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A68E106566B for ; Thu, 28 Feb 2008 14:31:38 +0000 (UTC) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id A1CE58FC18 for ; Thu, 28 Feb 2008 14:31:37 +0000 (UTC) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id A2BBA9B75E; Thu, 28 Feb 2008 15:31:36 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [192.168.200.102] (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 5529A9B65B; Thu, 28 Feb 2008 15:31:35 +0100 (CET) From: Marko Zec To: Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?= Date: Thu, 28 Feb 2008 15:31:27 +0100 User-Agent: KMail/1.9.7 References: <47C39948.3080907@elischer.org> <200802280343.57576.zec@icir.org> <86tzjt1ar3.fsf@ds4.des.no> In-Reply-To: <86tzjt1ar3.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200802281531.28052.zec@icir.org> Cc: Julian Elischer , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2008 14:31:38 -0000 On Thursday 28 February 2008 14:17:04 Dag-Erling Sm=C3=B8rgrav wrote: > Marko Zec 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