scope of scheduler.c and trx_sched_*
I notice that apparently osmo-bts-trx is the only caller of the trx_sched_* API, yet it is implemented in common/scheduler.c and compiled to libl1sched.a. Is osmo-bts-trx really the only caller? Also in osmo-bts-trx, the "trx" to me means SDR, like B200. But any BTS has one or more TRXs. So why isn't it osmo-bts-sdr? That's why I thought: maybe trx_sched_ is for all BTS models? Thanks for any clarification / confirmation :) ~Neels -- - Neels Hofmeyr <nhofmeyr@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 * Geschäftsführer / Managing Directors: Harald Welte
Hi Neels, On Wed, Jun 29, 2016 at 06:10:51PM +0200, Neels Hofmeyr wrote:
I notice that apparently osmo-bts-trx is the only caller of the trx_sched_* API, yet it is implemented in common/scheduler.c and compiled to libl1sched.a. Is osmo-bts-trx really the only caller?
Yes.
Also in osmo-bts-trx, the "trx" to me means SDR, like B200. But any BTS has one or more TRXs. So why isn't it osmo-bts-sdr?
In osmo-bts-trx, "TRX" means "A program behaving like an OpenBTS tranceiver and implementing the UDP based protocol of that", where the preferred implementation used by most people with osmo-bts-trx is probably "osmo-trx". It should probably still work with the original OpenBTS TRX or with the one from yateBTS. Note that all of this is a threoretical statement, I haven't used either of those configurations.
That's why I thought: maybe trx_sched_ is for all BTS models?
It's always useful to look at a call graph.
Thanks for any clarification / confirmation :)
simply look at the git log. commit 5538f5cff824f19d5dc8781cbb93525ad45ad833 and those following explain what was done and why it was done. The most important user I care about is osmo-bts-virtual, which also needs all the L1 scheduling parts. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
participants (2)
-
Harald Welte -
Neels Hofmeyr