From owner-freebsd-net@FreeBSD.ORG Wed Mar 3 09:52:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 473BE16A4CE; Wed, 3 Mar 2004 09:52:55 -0800 (PST) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A82D43D2D; Wed, 3 Mar 2004 09:52:54 -0800 (PST) (envelope-from zec@tel.fer.hr) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id D4E4A9B644; Wed, 3 Mar 2004 18:52:52 +0100 (CET) Received: from marko-tp.zavod.tel.fer.hr (marko-tp.zavod.tel.fer.hr [161.53.19.42]) by xaqua.tel.fer.hr (Postfix) with ESMTP id D4CD99B646; Wed, 3 Mar 2004 18:52:41 +0100 (CET) From: Marko Zec To: Takanori Watanabe , Julian Elischer Date: Wed, 3 Mar 2004 18:52:01 +0100 User-Agent: KMail/1.5.4 References: <200403030336.MAA24341@axe-inc.co.jp> In-Reply-To: <200403030336.MAA24341@axe-inc.co.jp> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403031852.01919.zec@tel.fer.hr> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, hits=-0.2 required=5.0 tests=AWL autolearn=no version=2.63 X-Sanitizer: Advosys mail filter cc: bzeeb-lists@lists.zabbadoz.net cc: james@physicalsegment.com cc: freebsd-current@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Was: My planned work on networking stack (vimage) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 03 Mar 2004 17:52:55 -0000 On Wednesday 03 March 2004 04:36, Takanori Watanabe wrote: > In message > , Ju > > lian Elischer wrote: ... > >The trick is that you need to be able to arbitrarily add a protocol, > >or a firewall stack or other modules. As I said it can be done. > >What is a problem is that 'static' form of the current vimage > >structure.. > > > >Even > > > >struct { > >#ifdef NETINET > > ..inet variables > >#endif > >#ifdef NETATALK > > .. appletalk variables > >#endif > >[etc.] > >} vimage; > > > >is not tennable because you cannot keep adding parts to the > > structure.. The whole aim of FreeBSD over the last 10 years has > > been to move towards modularity, in almost all areas. > > Generally #ifdef's are obstacles for making it moduler. > Exactly, and precisely for that reason the vimage/vnet structures had never included any conditional statements. The current approach is to include any networking symbol in the vnet struct, regardles whether the respective network family is configured / compiled in the kernel or not. As of today the vnet struct, which is less than 30.000 bytes long, includes all virtualized symbols from the net, netinet, and netipx trees. My assesment is that even if all relevant symbols from all supported networking families would be virtualized, the structure wouldn't grow beyond 100 kbytes or so... Which is still small enough for not to worry about a few wasted memory pages if certain network protocol family is not configured in the current kernel, so that the respective fields in struct vnet remain unused. Marko > >If you could add modules and have them add themselves to existing > >(or even only new) vimages, then it could be viable in FreeBSD. > > But networking stack itself now contains *many* #ifdef's, so > we cannot add ethernet protocol by kld, for example NETATALK now. > It may be done by all protocols layers are connected by netgraph(4). > > Static structure definition are certainly obstackles for making > moduler, but gathering protocol stack private values into a structure > will on the contrally help for it, by figuring out which data should > we duplicate