[openbeosnetteam] Re: mbuf.h
- From: "Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx>
- To: <openbeosnetteam@xxxxxxxxxxxxx>
- Date: Sun, 28 Sep 2003 14:44:47 +0200
Funny - I was starting to write a mail to you when I received this message. ;)
> > > Solution to fix that issue need more consideration.
> >
> > Why do we not fix it by finishing your new netstack together? ;)
> > I would stall PPP until the netstack is usable. The current netstack
> > is not usable, either, so I can only help finishing one of the two
> netstacks to be able to finish and test PPP.
>
> The current net stack is far usable than new_stack is, or will be in
> mid term.
So I should try to fix the current netstack?
I have plans to make PPP more general using net_layers and attributes (and the
new netstack). I would create a C++ wrapper API for this purpose (which you all
may use if you want ;). With those changes PPP would become much simpler than
now (as it removes the need for special PPPDevice, PPPProtocol and
PPPEncapsulator classes).
Only multilink support is problematic. The best would be to not implement it,
but make the API general enough to support multilink, but at the moment I do
not have a solution...
> What I've in mind is that each packet handler (that could be packets
> producers, consumers or both) have a upper (input) handlers list and
> downer (output) handlers list. But I don't think yet on how to assemble
> them, possibly with what Nathan call a layer name "protocol/flavor".
> See previous posts here about this topic...
I do not know any use for a list of layers below. One layer below should be
sufficient, IMHO.
Having a list of layers above the current layer is okay, though. ;)
How do you want to define a networking interface?
Is an interface a pointer to the main net_layer (e.g., ethernet/rtl8139/0)?
Where does the interface's name come from (maybe main net_layer's name)?
As far as I can see the protocols register themselves as individual net_layers.
Is this a good idea? Who owns the attributes, then? On the one hand, the ARP
cache could be global, on the other hand, the IP address attribute belongs to
only one interface.
Should not a driver_settings structure say which modules need to be added to
the interface?
Do you plan to support multiple attribute with the same name? The DNS module
will need something like this to store all nameservers (as the driver_settings
structure will add these attributes when the module is loaded, or do you have
something different in mind?).
> Another design point I've in mind is every stack addon should follow
> the same API, even if it don't implement all hooks.
Yes, I like that more, too.
> > OTOH, I cannot test the ethernet interface because I do not have a
> > network (only PPPoE).
> > Would loopback be sufficient? :)
>
> If you use PPPoE, you have an ethernet device in your system, or I miss
> something?
I meant that I do not have second computer to build a network. I could only
test ARP, but IP would only be available with PPP (for me, at least) or with
loopback.
> And it's "C" API, not C++. You all know why, I hope.
Of course, not. ;;)
> The new_stack is currently hosted bu an userland app called
> net_stack_server, that emulate kernel modules API,
> making debugging the stack easy.
Nice.
> If you wan't to see how it's working, here a *ready-to-try* version:
> http://philippe.houdoin.free.fr/phil/beos/openbeos/network_kit/
> new_stack-20030928.zip
>
> To try it, assuming you've at least one /dev/net/* device free to be
> used (disable it from Boneyard or net_server), run from Terminal:
> $ cd /where/ever/you/expand/the/zipfile/new_stack
> $ net_stack_server
Thank you, I already had a try a few days ago. It did not much except from the
test.
Waldemar
Other related posts:
