Date: Tue, 2 Mar 2004 14:13:44 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Marko Zec <zec@tel.fer.hr> Cc: freebsd-net@freebsd.org Subject: Re: Was: My planned work on networking stack (vimage) Message-ID: <Pine.BSF.4.21.0403021359220.62088-100000@InterJet.elischer.org> In-Reply-To: <200403022148.38002.zec@tel.fer.hr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2 Mar 2004, Marko Zec wrote:
> 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.
>
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.
If you could add modules and have them add themselves to existing
(or even only new) vimages, then it could be viable in FreeBSD.
> 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?Pine.BSF.4.21.0403021359220.62088-100000>