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/.
Pablo Neira Ayuso pablo at gnumonks.orgOn 04/05/11 11:02, Harald Welte wrote: > On Tue, May 03, 2011 at 11:29:16PM +0200, Holger Hans Peter Freyther wrote: >> On 05/03/2011 10:44 PM, pablo at gnumonks.org wrote: >>> From: Pablo Neira Ayuso <pablo at gnumonks.org> >>> >>> The daemon set up nanoBTS and HSL femto sockets by default, >>> ie. the three sockets to support these two drivers are open even >>> if we have no BTS of that kind. This patch enables them if they >>> are present in any configuration file. >> >> good goal, but maybe trigger this from within the VTY code? E.g. what >> if I want to add a HSL BTS to a running system? or start with no >> config file at all? Anyway our story of doing such config changes at >> runtime is not very good. > > yes, but I agree we should do this from the VTY code. At least all new > features we're adding should be more runtime vty based then thinking of > a config file that we parse once and then forget about it. > > So when we get a 'bts type ...' command (or when we leave the BTS_NODE) > we should check if the respective sockets are needed. You can find a patch attached to support what you describe, I tried to make as generic as possible. Please, have a look at the description. The new start(...) function for e1inp_driver objects could be use to replace the e1inp_init() call. The idea that I propose is to register the dahdi and misdn input drivers if we receive an "e1_input" command (via VTY or config file), then invoke start(...). BTW, e1inp_init() is only used by osmo-nitb, any reason for that? I also added a new attribute to the BTS model object, this field is useless for bs11. I found no way to relate e1inp_driver and bts objects in the case of hsl and ipaccess. This is usually done by means of the "e1_input" command in bs11, but its use does not make sense for hsl and ipaccess. > But yes, another big long pending TODO is to think about how we can > make most or even all runtime config changes work. Adding support for config file reload in runtime seems interesting to me, I would prefer changing things in the config file and reloading than typing all those VTY commands to add a new BTS, IMO. -------------- next part -------------- A non-text attachment was scrubbed... Name: ondemand-sockets-creation.patch Type: text/x-patch Size: 7643 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110505/47dfba4b/attachment.bin>