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/.
Max.Suraev at fairwaves.ru Max.Suraev at fairwaves.ruThank you for prompt reply Thomas. Some additional questions are inline. 11.02.2012 02:00, Thomas Tsou пишет: > How messy would option 1 be? Option 2 (or 3) more closely follows the > existing UHD model where the shared code is mainly limited to the > transport. I think that would be the best approach unless option 1 can > be done very cleanly. 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. > What is the difference between option 2 and 3? Does option 2 create a > second impl class within the usrp2 directory? I think a separate > directory is appropriate. This brings up another question: where does dispatching happens? E. g. which codepath is used to choose between usrp1, usrp2 and umtrx? For example If we use option 2 (separate impl file inside usrp2) and treat UmTRX as a special revision of usrp2 than dispatching happens in usrp2_iface.hpp: "enum rev_type" and every time get_rev() is checked. > b100 and usrp1 implementations were created based on copies of > existing usrp2 / e100 code without explicit class reuse. For example, > b100 / e100 / usrp1 exist separately, but share the same ad9862 codec. > There is some copied code between the three codec versions, but that > was less messy than creating a unified codec impl for all three. 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? -- best regards, Max, http://fairwaves.ru