Date: Tue, 2 Mar 2004 21:48:37 +0100 From: Marko Zec <zec@tel.fer.hr> To: Julian Elischer <julian@elischer.org>, James Read <james@physicalsegment.com> Cc: freebsd-net@freebsd.org Subject: Re: Was: My planned work on networking stack (vimage) Message-ID: <200403022148.38002.zec@tel.fer.hr> In-Reply-To: <Pine.BSF.4.21.0403021145080.62088-100000@InterJet.elischer.org> References: <Pine.BSF.4.21.0403021145080.62088-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 02 March 2004 21:01, Julian Elischer wrote: > The major problem with 'vimage' is that all statics are moved to a > large structure so that they can be duplicated... > e.g. The root of the interface list gets moved there so that each > vimage has its own list of interfaces. > > > This is ok for statically compiled modules, but what can you do for > adding new modules.. either statically of dynamically.. > > You end up having to have each module have it's own structure and > each vimage has to have its own list or array of such structures.. > Hi, Julian! True, this can also become an issue. However, the question is how many modules in real-life do require per network stack symbols/structures. For example, the original vimage patch already included the necessary hooks and reserved the appropriate fields for ipfw or dummynet to be loaded / unloaded dynamically with no major problems. On the other hand, no device driver should be affected by the virtualization, and shouldn't require any network-stack specific handling. And IMO the device drivers are those which are most commonly implemented as loadable modules. Cheers, Marko > > so to use the example above, > ifp = TAILQ_HEAD(ifhead) /* I forget the exact names */ > > becomes something like: > > ifp = TAILQ_HEAD((struct > netbase_statics*)(p->vimage[netbase_index])->ifhead); > > Where netbase_index is a global set when the networking base module > is loaded or linked in, (no idea by who), and the 'vimage' becomes an > array of void * pointers, each pointing to a different structure aof > variables that were once static, each structure being variables > related to a different module. > > > This could be done but it starts to look a lot like the TLS (Thread > Local Storage) stuff. > And it would pretty definitly have a performance impact. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403022148.38002.zec>