----- Original Message ----- From: "David Reid" <dreid@xxxxxxxxxxxx> > > [snip] > > Hmm, you could do it that way. How about a simple system where by each > module simply adds itself to a list of protocols it can speak, and what the > function call is? They all take the same parameters, so it's not a biggie. > > That way, i get an ipv4 packet, i simply do > > net_input(IPV4, ...) > > The net module knows where to find the ipv4_input function and so calls > it... > Yes it is a good aidea. But would the IPv4 module also tell the system where lower layers can find IP. Let's take a short example: IPv4 can be encapsulated in: * Ethernetv2 (type X) * 802.3-LCC (type Y) * 802.3-SNAP (type Y) * IPCP Data Frames (from PPP). Is it possible to make the IPv4 module annonce "I can understand IPv4" this way: "My module can handle data for TypeX for encapsulation Ethv2, Type Y for 802.3-LLC, etc". This definition should reside in something independant/external of the IPv4 module itself because we may want to add later other modules which may also decapsulate IPv4 packets (IP over ATM, ...). On the other hand, let's say we would like to add later IPv6 and we dont implement yet an IPv6 recognition in ethernet layer. If the IPv6 definition "file" tells that IPv6 can be found as ethernet v2 type 0x86DD then the ethernet layer can do its job with decapsulating IPv6 packets and forwar them to the IPv6 module. All this is fine for frames coming in the system and for path determination through modules. For the other direction (Where an IPv4 packet has to go if it must be sent on "the network" ?) As soon as we have a path from a network adapter (ethernet, loopback, etc.) to the IPv4 module then we can have a canditate IP endpoint related to one path to a "network connection" (I mean path from modules to modules). Ok, these are just some thoughts I share with us, don't know if this is clear of of any use :-p Regards, Emmanuel (reading its openbeaosnetteam mails as fast as possible :-)