I have one additional note:
For this case it is ok to replace one function with another and insert new one in the middle of the list in module_export.c, because this branch was used by few experienced developers yet.
Thanks for that, I wondered about that after I did it. And yeah, I should have read the comments
I think we will end up reworking some of this before we get it all right, so for the unstable branch, we should expect different builds will not be compatible. Try to put something in the commit message if you change it, but I wouldn't worry about version to version compatibility yet.
Reason of this requirement: to minimize modules size and core code, symbols are exported as indexes. So, module have no idea what real symbols are in the core. If order of the list is broken, then correspondence symbol is changed - old modules will call different symbol than they expect - module will hangup/shutdown/make bad things.
I would be strongly tempted to export symbols by name. Yes, it takes some RAM, but by going to modules, we've save a lot of RAM. In some cases, we can re-factor the interfaces so not so many exports are needed. Alternately, you could build a symbol map file with each build, then the loader could refer to that (but I don't think there's a need for this yet)
I'd also suggest we might want to break things up into specific APIs. So a module that only needs stdio can just say it needs stdio, and changes in other areas won't affect it.
In my build I use it as shortcut to call module inspector. So I can easily check at any moment is module loaded/unloaded or not, what impact to the memory.
Module inspector would be a good option for debug shortcut used for ram dump, prop/param paging etc.
1509
DNG code separate to loadable module. Some rewrites done to avoid float arithmetic using in module (and so bloating module size significantly). Works ok on my S95, compile ok for other platforms (but should be tested)
I don't understand the need for this. I would like to get some of the big questions resolved before we go turning everything into modules. With the current module setup, most cameras should have plenty of RAM, there's no need to shove every possible part into a module right now. If we make changes to how the module system works, then we need to redo every modules.
I know both phil and I have concerns about the current implementation, I would rather get the basics sorted out before adding even more modules. As I said before, I would have
much preferred to just put a few simple things in modules to start with. Since you already did the work, I took what you had done, but I really think this is making it harder for ourselves.
