On 04/19/2018 10:59 AM, Yichao Yu wrote:
> Ah, and I finally find that email I was referring to again,
> 
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-April/024653.html
> 
> which mentioned that
> 
>> - Main reason for customers registering custom message handlers was to
>> turn off logging to stdout and stderr. This is now a built-in feature;
>> we can control logging levels and other things at
>> configure/compile-time, and at runtime both via environment variables
>> and API calls.
> 
> Unless it is recommented for everyone to compile their own library
> instead of using binary packages, I don't think a compile time option
> is a usable solution to this need.

Yichao,

I think it's clear now that the current state of UHD doesn't include all
the features that you want, so I think we can close out this thread.
For the record, it is perfectly reasonable to ask for additional
features here, and a runtime-disabling of the fastpath messages is not
something that is terribly complicated to implement. However, please
consider that while *your* particular application would like to have a
UHD feature that doesn't exist, this hasn't come up before, and we
balance feature requests (of which we get a lot) based on frequency of
request, perceived importance, etc. We are very happy to add features
that people need, but we can't anticipate all possible things people
could potentially ask for.

> (And if one has to compile the library, why does the ettus uhd PPA
exists....)

I'm not sure if this is a legitimate question, or if you're complaining
that the PPA is not configured to your particular taste, but the purpose
of the PPA is to provide *one* standard configuration of UHD as a binary
state. Other users might require other configure/compile time settings
(maybe disable certain boards, change default paths, etc.), and in that
case, same as yours, recompiling is the correct option. Providing
binaries for every version *and* every combination of UHD settings would
be nice, but it's also not feasible.

Regards,
Martin

_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to