[openbeosnetteam] Re: Status

Oliver Tappe <openbeos@xxxxxxxxxxxxxxx> wrote:
> > I don't know. It might be wise, and it might even be the shortest 
> > way
> > to achieve something, but I wouldn't like what ends up in our
> > repository: this large blob of foreign code.
> > I especially dislike the directory structure and naming scheme 
> > found in
> > BSD code, combined with an extensive use of macros. Furthermore, it
> > delivers much more than we need.
> Actually, I don't know myself either. The code is ugly and I feel 
> uncomfortable with it, short: I love it as much as glibc >;o)
> 
> I just thought it would be easier to get the stack into a working 
> state 
> fast and then proceed from there, i.e. break out and clean up module 
> by 
> module. This would have the advantage that we could check for 
> regressions 
> as we work on the modularization, since we could test the stack by 
> actually 
> using it (then again, we could do that with our current stack, it 
> just 
> doesn't work properly at the moment).

Since we all seem to like that code so much, maybe we should step away 
from the idea of porting the FreeBSD stack? We could still use it as a 
coding reference (ie. what has to be done and how should it work etc.).
With you, Andrew, and me, and maybe someone else like Marcus jumping 
in, we've quite a bit engineering power at our hands to implement a 
clean stack based on FreeBSD and what we have (and other sources, as 
well, if preferred).

> > Since understanding and solving locking issues caused by working 
> > around
> > the netisr stuff requires a good understanding and overview over 
> > the
> > existing code, this is a good source of introducing hard to track 
> > bugs
> > (or performance bottlenecks) as well. 
> Yes, that's correct, but I don't see how the layer-by-layer approach 
> helps 
> with this, especially since the netisr stuff is used for transition 
> between 
> different layers.

A layer-by-layer or module-by-module approach wouldn't duplicate the 
FreeBSD architecture, and thus, wouldn't be based on netisr to work.

> [ 8< ]
> > For what do we need the tx-thread, btw? Is that additional 
> > handshake
> > needed for anything?
> That thread pushes data from the interface queue to the driver, so I 
> guess 
> dropping it would break the stack (as there would be no more 
> interface 
> queues).

Sure, but I don't see why a simple write() in the processing thread 
isn't enough. It doesn't make much sense to write the packets 
internally faster than what the output device can do.

> [ 8< ]
> > What parts of the stack do we want to adopt? I guess net/netinet 
> > are
> > the minimum of what's required (possibly netgraph, too, dunno about 
> > the
> > references yet).
> I don't think netgraph is required, so I suppose it's net & netinet 
> until 
> we find out otherwise...

Okay, the userland tools may want to be adapted, too, at some point.

Bye,
   Axel.

Other related posts: