GNU Radio 4.0 Preliminary Code Review: Difference between revisions

From GNU Radio
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 11: Line 11:
: subprojects - CLI11, cpp-httplib, cppzmq, json, moodycamel, pmt
: subprojects - CLI11, cpp-httplib, cppzmq, json, moodycamel, pmt
: QA tests
: QA tests
: Domain specific blocks/buffers - e.g. CUDA
* Domain specific blocks/buffers - e.g. CUDA
* Don't have a good solution for making this out of tree but still cohesive (same block with multiple impl)
** Don't have a good solution for making this out of tree but still cohesive (same block with multiple impl)


; gnuradio-runtime --> gr namespace
; gnuradio-runtime --> gr namespace

Revision as of 11:03, 28 March 2022

Prior to bringing newsched into the main gnuradio repository under a dev-4.0 branch, it is necessary to get at least a preliminary review so that the main aspects of the design can be understood and discussed. Let's use this page to document proposed changes to the existing newsched design that need to be done either before or after the mainlining.

License
GPLv3 - probably don't have much choice here unless we want to have some parts under a different license (e.g. PMTF under lgpl)
Build System
meson.build - has been tremendously easier than CMake to deal with (some caveats)
Code Structure
overall arrangement of code
subprojects - CLI11, cpp-httplib, cppzmq, json, moodycamel, pmt
QA tests
  • Domain specific blocks/buffers - e.g. CUDA
    • Don't have a good solution for making this out of tree but still cohesive (same block with multiple impl)
gnuradio-runtime --> gr namespace
runtime is now a modular concept so previous gnuradio-runtime just called gr
Schedulers
  • Scheduler API
  • CPU Scheduler
Message Ports
Buffers and Custom Buffers
Block API
block.h, node.h, port.h
  • Main diffs from GR3
    • No history
    • No forecast
    • Less scheduler "hints"
    • Self contained work() function
Block Autogen
yaml file format
jinja templates
create_{mod,block} scripts
Block Porting
what is involved and what can be automated?
Options for shimming 4.0 blocks back into 3.x?
Kernel Library
Separation of kernel namespaces into different library that doesn't depend on blocklib
Distributed Operation (concept)
Minimal example able to partition and run across instances
Documentation
Opportunities for cohesive versioned docs
Loss of public block header through doxygen
Benchmarking
What to include in-tree
GRC
Changes needed to support 4.0 features
Plan to move out of tree??
Coding Standard
C++ modernization
clang-format changes