From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 09:57:59 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2E3716A400 for ; Wed, 14 Mar 2007 09:57:59 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id D2AFC13C45E for ; Wed, 14 Mar 2007 09:57:45 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2E9vT3w002885; Wed, 14 Mar 2007 12:57:29 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2E9vQS4002882; Wed, 14 Mar 2007 12:57:26 +0300 (MSK) (envelope-from yar) Date: Wed, 14 Mar 2007 12:57:26 +0300 From: Yar Tikhiy To: Luigi Rizzo Message-ID: <20070314095725.GA1766@comp.chem.msu.su> References: <20070310153534.GA35834@comp.chem.msu.su> <20070313004543.A54774@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070313004543.A54774@xorpc.icir.org> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: Who is to load dummynet.ko? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 09:57:59 -0000 On Tue, Mar 13, 2007 at 12:45:43AM -0700, Luigi Rizzo wrote: > On Sat, Mar 10, 2007 at 06:35:34PM +0300, Yar Tikhiy wrote: > > Hi folks, > > > > Just noticed that neither ipfw(8) nor /etc/rc.d/ipfw cares to load > > dummynet.ko. It can result in a broken setup when one migrates > > from a custom monolithic kernel to GENERIC with modules, which is > > a nice way to reduce support headache today. > > > > There are at least two possible ways to deal with the issue. The > > easy way is to give the task of loading dummynet.ko to /etc/rc.d/ipfw. > > The problem with it is that the script cannot know in advance if > > dummynet is really used by the ipfw rules to be loaded. The decision > > whether to load the module is left to rc.conf(5) in this case. > > i think this is a reasonable option and the one to use for all ipfw > extensions (divert, dummynet, in-kernel nat and so on). Thank you for your reply! Loading dummynet via rc.d is really easy, I think I can add it. However, I'm afraid it won't be a real long-term solution -- please see below. > Making the load on demand would require a bit of additional code because > it depends on the actual rules being loaded, and the rules are not > parsed at load time. Plus, i believe that in a case like this > the decision of which modules to load should be a conscious one > taken upfront by the system administrator (i.e. end up in rc.conf > or loader.conf) rather than be the result of the actual ipfw > configuration. Well, I used to stick to this opinion, too, in the good old days. But today we are growing more and more modularity in our kernel, and it's a nice feature to have. With a lot of modules, the issue of double configuration appears: if I want feature FOO, I have to add its configuration AND not forget to load the respective module. It can be a pain as the number of such cases rockets up. Today at least mount, ifconfig, and netgraph provide for loading modules on demand, with the former two being system's core components. I've just taken a look at the ipfw userland utility code. It notices a "pipe" or "queue" keyword in its command line rather early, and it can be a good moment to check and load dummynet.ko. Ditto for divert. Or the inner function do_cmd() can load a missing module before issuing setsockopt(), which is even better as we won't load the module on a read access or if the command line contains a syntax error. do_cmd() can even load ipfw.ko itself so that people no longer have to type, e.g.: (kldload ipfw && ipfw add 65000 allow ip from any to any) > /dev/null 2>&1 insead of just: ipfw add 65000 allow ip from any to any if a need to load ipfw.ko for some experiments arise. > > The second way is to move the task of loading modules to ipfw(8). > > Then it could load ipfw.ko, divert.ko, and dummynet.ko on demand. > > cheers > luigi -- Yar