Hi, > Unfortunately, this moves the knowledge of how a domain works into GNU > Radio, and away from the code/coders that know about it. It would mean > that any time a different co-processor or hardware offload design comes > up, GNU Radio itself would have to change, and designers would have to > have knowledge of GNU Radio internals in order to develop their code.
Not necessarily. I would see those "domain objects" be handled like blocks, pluggable. And GR would have some for very standardized stuff (typically the current default behavior / host memory) and you could have some in external tree / projects. If someone has an interface that's completly custom, they could ship their domain plugin right along their custom block that uses it. > I suggest that a way to implement domain-specific knowledge across > multiple blocks, allowing the kind of optimization you describe above, > would be to make a parent class for each domain that the blocks of that > type all derive from. Well, it's not that far off from what I was thinking. But doing it via inheritance on the block level rather than by delegation to a 'domain object' has one downside in my mind : It's global to the block. While OTOH delegation could be part of the io signature and per-port. I can see some blocks having input / output ports in different domains with different requirements. Cheers, Sylvain _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio