libosmocore wishlist

While working on the talloc context patches, I was wondering if we should spend a bit of time to further improve libosmocore and collect something like a wishlist. I would currently identify the following areas: 1) initialization of the various sub-systems is too complex, there are too many functions an application has to call. I would like to move more to a global "application initialization", where an application registers some large struct [of structs, ...] at start-up and tells the library the log configuration, the copyright statement, the VTY IP/port, the config file name, ... (some of those can of course be NULL and hence not used) 2) have some kind of extensible command line options/arguments parser It would be useful to have common/library parts register some common command line arguments (like config file, logging, daemonization, ..) while the actual appliacation extending that with only its application-specific options. I don't think this is possible with how getopt() works, so it would require some new/different infrastructure how applications would register their arguments 3) move global select() state into some kind of structure. This would mean that there could be multiple lists of file descriptors rather than the one implicit global one. Alternatively, turn the state into thread-local storage, so each thread would have its own set of registered file descriptors, which probably makes most sense. Not sure if one would have diffeent 'sets' of registered file descriptors in a single thread. The same would apply for timers: Have a list of timers for each thread; timeouts would then also always execute on the same thread. This would put talloc context, select and timers all in the same concept: Have one set of each on each thread, used automatically. Any other wishlist items? -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)