[openbeosnetteam] Re: Protocols types

Axel Dörfler wrote:
> Waldemar Kornewald wrote:
> > > I don't like hard coded (in the wrong modules), but I dislike
> > > configuration files even more.
> >> ...
> > ...
> > How will it be done in the final implementation? The current ethernet
> 
> > module
> > has its values hard-coded. Where should the values be put? Should 
> > each
> > module maintain its types (ethernet has a list of all ethernet 
> > subtypes, PPP
> > has its own list, etc.) or should the core module maintain its types?
> 
> > Each
> > module is the best, but why does the ethernet module not do this, 
> > then?
> > Because it is just there to have something working?

Because David, former developer, choose once to merge ARP protocol module 
within ethernet interface module. 
At start ARP was a separate protocol module like others, and I can't remember 
why he choose this...

Anyway, even without the embebded arp support, this switch in 
ethernet.c:ethernet_input() should not be there but in stack datalink layer.
Oh, there is no datalink-layer technically speaking in current code.
I miss him! ;-)

In current stack design, all is stored in a global linked list of protosw 
struct. It contains all protocols info, for all levels of network stack 
(NET_LAYER1 = lower to NET_LAYER4 = upper- where are the 7 ISO levels?!).
Each protocol module will ask (thru add_protosw() function) the stack to fill a 
local proto array which'll contains all protocols of same level or by one level 
upper or downer.

Look at this protosw struct, directly coming from BSD land, in 
current/headers/posix(!?)/sys/protosw.h

It take time to understand how this whole protosw list works.
It's complex, but in fact not very flexible, due to artificialy limited levels 
number.

> That's what I meant with "in the wrong modules".
> The ethernet shouldn't have hardcoded with which other modules it can 
> work with. But, the other modules should know that they work with that
> specific ID which came from that layer.
> I think either the ethernet module or the stack itself should then 
> stick the pieces together so that it all can work.

Yes. Dunno yet what's the best way to achieve that from hardcoded stacking 
or external-config-file-based stacking of protocols.
Or another, better solution. 

I don't like the first one, but find the second choosed by BONE still not that 
clever. Feel free to make any suggestion on that very topic.

Outgoing data can be simple as (after modification) down data like this:
protocol1 -> protocol2 -> [...] -> protocoln -> datalink layer -> interface 
-> write data on interface device
A linked-list built at each socket creation can handle this very well.
Even better if each *node* publish a function for "passing down" data (let's 
call it send_data()) with same prototype.
It's BONE design: look at bone_proto_node struct.

But, for ingoing data, it's not that easy. No protocol can say  "this one is 
for me!" before looking at data.
Maybe chaining all protocols of same auto-proclamed level and give them the 
data until someone "take it" and push it up instead of calling "not mine, 
next!" would be more flexible.
But what about performance?!

-Philippe

Other related posts: