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/UmTRX@lists.osmocom.org/.
Thomas Tsou thomastsou at gmail.comOn Sat, Feb 11, 2012 at 6:47 AM, <Max.Suraev at fairwaves.ru> wrote: > I think we would stick to option 3 (separate umtrx folder) - because it'll become > pretty messy over time (essentially every place where clock or codec controller is > used requires alteration). Also It seems that with this approach it will be easier to > push UMTRX support into upstream once it's mature enough. Those are good points. I agree. > This brings up another question: where does dispatching happens? E. g. which codepath > is used to choose between usrp1, usrp2 and umtrx? Each "usrp" has it's own find / make calls that are registered into the "device function registry container" before main(). That occurs with the UHD_STATIC_BLOCK macro, which is basically a memberless, constructor object. When called, the device::find and device::make iterate through the registered find / make tuples. I think 'make' uses the first discovered device if no arguments are passed in. > Is there some technical reason why we can't use something like '#include > "../usrp2/io_impl.cpp"' inside /umtrx/umtrx_iface.hpp for example? Or it's purely > question of aesthetics? Not really. For the current Ettus devices, the io_impl.cpp implementations really are different, so it doesn't make any sense. Thomas