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/.
Oliver Smith osmith at sysmocom.deIs this for big refactoring wishes only? If not, I would like to have ^L working in telnet VTY connections like in a typical terminal: make it clear the buffer. 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 > > 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? > -- - Oliver Smith <osmith at sysmocom.de> https://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