Was: My planned work on networking stack (vimage)

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..


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.


On Tue, 2 Mar 2004, James Read wrote:

> > I still have in mind that I would like to see vimage[1] in HEAD one day
> > ... I think it would be a pretty cool feature to have. If one can keep
> > this in mind when doing greater modelling on the network stack it
> > might help the one who will - at some time - find the time to
> > ingtegrate it.
> >
> >
> > [1] http://www.tel.fer.hr/zec/BSD/vimage/index.html
> >
> 
> 
> 
> </Off Topic>
> 
> In my opinion, this would be a _VERY_ good 'feature' to add into the system.
> As it stands there is minimal 'networking' in a jail from a users point of
> view, and also an administrators view aswell (granted this isnt exactly what
> jail was designed to do, and so on). This could be more then an asset to the
> whole jail architecture, by providing a clone-able network stack within
> jails. For instance, you could then run programs/services like NFS etc from
> jail to jail without having to lock down services offered from the jail
> 'host'.
> 
> If this can in _any way_ be pushed/implemented (with minimal distruption) so
> that is it in HEAD/CURRENT then its well on the way to complementing what
> 'jail' does.
> 
> This is one thing that I would like to use, without patching systems. But
> then thats just my 'wish list' opinion of it.
> 
> Regards,
> 
> James.
> 
> ( I apoligise for the cross post, it's my first time posting to -current
> & -net, I just thought it would be worth my 2c )
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> Mailscanner thanks transtec Computers for their support.
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>