[openbeosnetteam] Re: Status
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Tue, 13 Jun 2006 01:08:06 +0200 CEST
"Andrew Galante" <haiku.galante@xxxxxxxxx> wrote:
> Axel wrote:
> >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.
> >But anyway, what do you think we should do? Have I managed to alter
> >your opinion?
> You mean like the ipv4 module, tcp module, etc? Keeping the BSD code
> together will make it easier to upgrade or fix bugs if any are found
> in
> FreeBSD.
I'm not at all worried about bugs in the FreeBSD stack - since it has
been part of the 6.1 release it's probably already better tested than
the Haiku networking stack will ever be for R1 :)
And even if this is a short term advantage, the aim of a clean and
modular architecture will nullify it again.
> Oliver wrote:
> >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).
> Sounds good. We should keep the code fairly organized, so that if
> bugs are
> found in FreeBSD, it would be fairly simple to track down the
> relevant
> sections in Haiku.
As I said above, I don't see this as a big advantage. What would
definitely be an advantage is the possibility to be able to better
check for regressions. But then again, having a testing suite of some
kind would probably help the most, no matter from where we start.
> I don't know the Haiku code well enough to make a decision about what
> functionality is performed by which thread.
That has nothing to do with Haiku, actually; it's a basic design
decision we should flesh out as early as possible.
> As far as sysctl vs ioctl goes, I'm not fond of the /dev/net/stack
> "device
> that is not a device." If it makes the stack easier to work with,
> I'll go
> with it.
A device is one way to export kernel functionality. And since we need
file descriptors here for an external (the networking stack will always
be an optional module) service, there simply is no other clean way to
achieve this.
Bye,
Axel.
Other related posts:
