Re: Was: My planned work on networking stack (vimage)

On Wednesday 03 March 2004 04:36, Takanori Watanabe wrote:
> In message
> <Pine.BSF.4.21.0403021359220.62088-100000_at_InterJet.elischer.org>, 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