From owner-p4-projects@FreeBSD.ORG Wed Apr 18 03:30:26 2007 Return-Path: X-Original-To: p4-projects@freebsd.org Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id DCE3E16A404; Wed, 18 Apr 2007 03:30:25 +0000 (UTC) X-Original-To: perforce@freebsd.org Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9285B16A400; Wed, 18 Apr 2007 03:30:25 +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 20D1613C484; Wed, 18 Apr 2007 03:30:25 +0000 (UTC) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 171759B649; Wed, 18 Apr 2007 05:11:16 +0200 (CEST) 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.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [192.168.200.106] (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 406349B646; Wed, 18 Apr 2007 05:11:15 +0200 (CEST) From: Marko Zec To: Julian Elischer Date: Wed, 18 Apr 2007 05:10:54 +0200 User-Agent: KMail/1.9.1 References: <200704161051.l3GApuxA044256@repoman.freebsd.org> <4623EC51.4080407@elischer.org> In-Reply-To: <4623EC51.4080407@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704180510.54729.zec@icir.org> Cc: Perforce Change Reviews , Marko Zec Subject: Re: PERFORCE change 118226 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 03:30:26 -0000 On Monday 16 April 2007 23:36, Julian Elischer wrote: > Marko Zec wrote: > > - pf can now be kldloaded, but is not virtualized (yet) > > I was thinking that the following might be an interesting > way to think about modules.. > > kldloading a module is 2 parts.. > 1/ loading it in to memeory > 2/ linking it in > > In the base vimage you do both, but in the others, > then you only can link in modules that are already loaded. > > i.e. each vimage is responsible for linking the modules that it > needs (?) > > loading a new module to memeory doesn't mean that the functionality > is automatically available for all existing vimages... > > child images do not inherrit all the linked modules of the parent.. > they need to link in those they need. Yup this looks neat but could become an implementation nightmare. For example in case of pf, to some "stack" instances we would have to expose the /dev/pf entry, while to those others that haven't been "locally-kldloaded" we shouldn't. Or consider the sysctl interface in say ipfw - we would have to implement additional logic for hiding the sysctl nodes to those stack instances that haven't "loaded" the ipfw module. But most importantly this would complicate traversing over stack instances in those code chunks that need to traverse through all stacks, many timers for example. Those would now need to maintain separate per-module lists of active (loaded) and inactive instances - a nightmare of its own. And finally we would have to take extra care about dependencies. I.e. which modules must be unconditionally loaded in all stacks (like INET and INET6), and which can be left unattached until later explicitly requested by the instance owner. But I see the drive for this, both in terms of conserving system resources, and in preventing shoot-in-the-foot scenarios, like kldloading ipfw and then instantly breaking IP communication in all existing stack instances if ipfw was not compiled with DEFAULT_TO_ACCEPT... So this idea needs more thought... Marko