[openbeosnetteam] Re: Status
- From: Oliver Tappe <openbeos@xxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Mon, 12 Jun 2006 23:39:42 +0200
On 2006-06-12 at 15:44:31 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
wrote:
>
> Oliver Tappe <openbeos@xxxxxxxxxxxxxxx> wrote:
>
> > In order to facilitate getting comfortable with the subtleties of
> > such a
> > large blob of foreign code, I suppose that it'd be very wise to try
> > and
> > import the new stack with as few changes as possible. We know that
> > the code
> [...]
>
> 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 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.
> We also don't want to end up with
> a dozen networking threads if it can be avoided.
Ok.
> In the longer term, I would prefer a BONE like architecture with a
> useful separation of code and functionality into modules. That's why I
> would like to do this transition module per module.
I surely agree that having a BONE like architecture is what we're aiming at.
> But anyway, what do you think we should do? Have I managed to alter
> your opinion?
Well, I can see your points and I don't really mind going either way.
Andrew, do you have an opinion on this?
[ 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).
[ 8< ]
> > Ah, and of course, before all that...
> >
> > 0.) We should import the FreeBSD stack. I'm not very familiar with
> > svn, so I
> > am not sure how to do this properly. What about doing this?
> > - import the FreeBSD-6.1-release netstack into a vendor branch
> > - create a new netstack branch of module haiku under team/network
> > - copy files from the vendor branch into the netstack branch as
> > seems appropriate/necessary
> > - start work in the network branch, very likely dragging more files
> > from the vendor branch along
> >
> > Comments on these ideas are very welcome!
>
> 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...
cheers,
Oliver
Other related posts:
