> 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