libosmocore wishlist

[Harald Welte]

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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)