This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Pau Espin Pedrol pespin at sysmocom.deHi, On 3/20/19 11:13 AM, Harald Welte wrote: > 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 1 and 2 not really worth for me. I'm not against it, but I'm happy enough with current state. > > 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. Turn sate into thread-local storage makes sense. No need for different sets per thread imho. Loosely related: It may be good to refactor code to allow for other polling systems (like epoll()), which may be more efficient if we have a long set of file descriptors but only a few are triggered every loop step. Regarding some other thread you wrote recently, I don't see much issue in having VTY library code not supporting multithread,since you can always force polling it from same thread and then if your process is multithread you take care of message passing between threads yourself in the VTY app-specific code. For logging code we may want to add some callback which provides the application with some way to lock/unlock a mutex or something similar. If cb is NULL, then there's no performance penalty during logging. Regards, Pau -- - Pau Espin Pedrol <pespin at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte