[openbeosnetteam] Re: Protocols types

  • From: "Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx>
  • To: <openbeosnetteam@xxxxxxxxxxxxx>
  • Date: Thu, 10 Apr 2003 21:48:00 +0200

> I don't like hard coded (in the wrong modules), but I dislike
> configuration files even more.
> The stack should scan through the available modules (even on request
> when a new one is added at runtime, could be done with node monitoring
> in the new kernel), and should ask them what services they provide.
> I don't think it's very user-friendly when you first have to config
> something that obvious and all files are already in place anyway. So,
> if we can avoid such a config file, we should do it, IMO.

Right, but how do we want to implement Appletalk into Ethernet and PPP? We
would at least need a hard-coded table in the core module. What if someone
adds even other base protocols? How do the upper protocols know their types
for this base protocol?
Say, we do neither have PPPoE nor PPP support, but only Ethernet. Now,
someone wants to add PPP support. He must hard-code the supported protocol
types. Then, someone wants to add PPPoE. How does he tell the Ethernet
module that PPPoE needs the types 0x8864 and 0x8863? Does he have to
implement his own Ethernet support? There will be no routing possible...
Will everybody have to wait until we release new modules supporting these
types or could a programmer sit down and port the PPP(-oE) module from
FreeBSD?
It is not that complicated to update the ID list when protocols are added,
but it needs someone who updates our tables and the user must install the
update.

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?

Waldemar


Other related posts: