> As I already tried to explain, C++ in the kernel is *not* usable that > way now until we have real shared libraries, at least not if you want > to implement the net stack as a module. > You can't export a C++ API in modules, and therefore, you can't inherit > from a class defined in a module - C++ can currently only be used per > module, but not really inter-modular :) That is clear to me and this is the reason why I want to use a static library that contains all classes. It, of course, makes changes in the core impossible without recompiling all other modules, but as we will be the only ones who develop such modules it is no problem. At least, it will work until we get shared libraries in the kernel. Then, we can change the core module (e.g.: eliminate bugs) and all modules will profit. > Furthermore, with a C API you can implement your modules in both, C and > C++ - with a C++ API you force all add-ons to be written in C++, and > that's certainly something I don't want to do at this point. The alternative would be that we use a C API to access all module functions and these functions call the C++ implementation. Additionally we have some C++ wrapper classes, so that all modules are implemented in C++, but they do not have to be. This might be the best solution. For my ppp_interface_manager module I plan to export a C-like API that gets C++ interface objects as parameters (can we call it C then?). The reason for this is that there should be only one interface manager. If it is a class it can be instantiated by everyone.With a trick we could use a friend function that allows this, but a function with the same name would allow it in every other module, too. For instance, the interface manager talks to our netstack to add ppp interfaces. It maintains a list of already used interfaces. If now someone instantiates a Manager object we get in trouble because it will try to allocate "ppp0" which is already in use by the Manager object in our interface manager module. It will fail. Thus, there should be no C++ objects representing the real interface. C wrappers are much better. Additionally we can add C++ access objects for the C module APIs. Is that understandable? :) Here is an example: // manager.h typedef struct manager_info { void (*add_protocol) (Protocol *object); // Protocol is an object, but add_protocol points to some C function } manager_info; // manager.c (the real module) class Manager { void AddProtocol(Protocol *object); }; static Manager core; void add_protocol(Protocol *object) { core.AddProtocol(object); } manager_info info = { &add_protocol }; No doubt, this is more work, but nobody will ever create a Module object (except the module that implements the API). Or do you think it is better to have a pointer to the object in the module_info and hope that nobody tries to create one in his own module? Waldemar