Hi all, Despite what it may seem, my recent changes to clean up the header files were not superficial. They are part of a strategy to create a version of libopenocd that can be considered stable enough for production development of high-level applications (e.g. custom GUIs).
Since I have hit the point where some decisions need to be made that will have outwardly visible effects on the tree, I am posting my complete plan for consideration in the hope that the community will endorse it (or expose any holes in it that I may have missed). Lack of feedback will be interpreted as tacit endorsement of all of its details, and I will continue to press forward on these lines of development. ;) While the exact order of these steps may change (or run concurrently), here is the rough outline of tasks that I think need to be completed: * Trim headers to identify existing module dependencies (mostly done). * Eliminate redundant #include directives to produce minimal graph. + Break remaining trivial header dependencies (researched). * Remove config.h from types.h; make all .c files #include it (done). * Definitions from config.h should NOT be used in public header files. * Many such symbols _are_ used therein, but removing them comes later. + Eliminate remaining superfluous intermodule dependencies (researched). - Move improperly placed routines to better locations. - Remove all up-calls (low-to-high layer violations: add callbacks). + Identify public header files (research in progress): + Which do we want: <jtag.h> or <jtag/jtag.h>? ** - Create new headers for those that mix public and private APIs. - Move private foo.h bits to foo_imp.h (other ideas?) - Remove all feature condition tests from public header files: - External APIs should be made constant w.r.t. feature sets. - Add stubs that return ENOSYS (or equivalent) for missing features. - Update APIs to support dynamic driver loading: - eliminate all static driver linkages - add/find generic plug-in library for dynamic shared library loading - convert driver interfaces to load required modules at run-time - Decide how to deliver the factored modules. Should we: - produce each module as separate library (e.g. libocdhelper), or - just go with a monolithic libopenocd library? (TBD much later.) - Refine the public interfaces to produce first stable library version. Please let me know if I have left anything important that is required (or desired) for the overarching "libopenocd" strategic task. With these tasks done, the external interfaces could be called "stable"; in other words, this should be more than sufficient for the library to be used in production environments, not that our work would be done. However, packagers could produce independent updates of the OpenOCD library and its various forthcoming CLIs, GUIs, and plug-ins. :) I believe this plan would be worthwhile for the community in the end. The architectural improvements will give OpenOCD more modularity and extensibility. I have started or finished the first few tasks, and the remainder will not be terribly difficult; it's just a lot of diligent maintenance work. Cheers, Zach ** I vote for the more obvious <target/somestrangechip.h> over <somestrangechip.h> (since the later could also potentially be <jtag/...> or <flash/...> to new users). _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
