Date: Wed, 03 Mar 2004 12:36:56 +0900 From: Takanori Watanabe <takawata@axe-inc.co.jp> To: Julian Elischer <julian@elischer.org>, zec@tel.fer.hr Cc: freebsd-net@freebsd.org Subject: Re: Was: My planned work on networking stack (vimage) Message-ID: <200403030336.MAA24341@axe-inc.co.jp> In-Reply-To: Your message of "Tue, 02 Mar 2004 14:13:44 PST." <Pine.BSF.4.21.0403021359220.62088-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.21.0403021359220.62088-100000@InterJet.elischer.org>, Ju
lian Elischer wrote:
>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.
Generally #ifdef's are obstacles for making it moduler.
>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
.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403030336.MAA24341>