From owner-freebsd-virtualization@FreeBSD.ORG Sat Dec 13 20:10:07 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7744410656A3; Sat, 13 Dec 2008 20:10:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id F28588FC17; Sat, 13 Dec 2008 20:10:06 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 2048F41C6A3; Sat, 13 Dec 2008 21:10:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id AL8qj7J-9cEK; Sat, 13 Dec 2008 21:10:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id BC8A041C6A1; Sat, 13 Dec 2008 21:10:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 1A8434448D5; Sat, 13 Dec 2008 20:07:38 +0000 (UTC) Date: Sat, 13 Dec 2008 20:07:38 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Max Laier In-Reply-To: <200812132045.17207.max@love2party.net> Message-ID: <20081213195343.V97918@maildrop.int.zabbadoz.net> References: <200812131913.mBDJD38C037353@svn.freebsd.org> <20081213191345.M97918@maildrop.int.zabbadoz.net> <200812132045.17207.max@love2party.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@freebsd.org, FreeBSD current mailing list , FreeBSD virtualization mailing list , freebsd-net@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: HEADS UP: vimage - virtualized global variables in the network stack X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2008 20:10:07 -0000 On Sat, 13 Dec 2008, Max Laier wrote: > On Saturday 13 December 2008 20:33:53 Bjoern A. Zeeb wrote: > ... >> This state of having the variables in parallel, global and in the >> container struct, will be maintained for another (short) time until >> the entire virtualization framework is in. This is needed, so that >> all three possible states can be benchmarked from exactly the same >> code changeset. >> >> >> For developers comitting new code or changing code it is important to >> properly add virtualized variables in the way that: >> 1) the globals and externs (if needed) are added/kept in sync as both >> a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate >> container struct + the V_ macro. >> When used somewhere in code one has to use the V_foobarbaz version. > > Is there (an easy) way to have the tinderbox build every other run without > VIMAGE_GLOBALS so that the most obvious error (global available, but not in > the container struct - or the other way around) can be warned about? Without VIMAGE_GLOBALS is the default; we have been building this for a few days already. The flip had been so smoothly that almost noone had really noticed. Marko has done a really great job! Thus my HEADS UP now after I am confident enough that (almost) all places were caught and clean. In case you want to check yourself you can simply put a file into one or multiple archs conf dir that looks like: ------------------------------------------------------------------------ > cat sys/amd64/conf/LINT-VIMAGE_GLOBALS include LINT ident LINT-VIMAGE_GLOBALS options VIMAGE_GLOBALS ------------------------------------------------------------------------ I am doing that build every other day from now to catch the possible error of a virtualized variable in the container struct w/o the global. But as this is the least problematic case I do not want to commit the kernel configuration as it'll make builds longer for everyone, etc. The more problematic cases that builds cannot catch are: - static initialization of a virtualized 'global'. - a newly added virtualized 'global' that is not under #ifdef VIMAGE_GLOBALS I have scripts to identify the latter already. The former will only be caught be either code inspection or "unexpected results" when running. /bz -- Bjoern A. Zeeb The greatest risk is not taking one.