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. >Received on Tue Mar 02 2004 - 11:49:31 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:45 UTC