13 Feb
2012
13 Feb
'12
4:18 a.m.
On Sat, Feb 11, 2012 at 6:47 AM, <Max.Suraev(a)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