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
No comments:
Post a Comment