GNU Radio 4.0 Preliminary Code Review

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)

Git History

Very divergent - do we start from scratch and let 3.x and 4.0 each have their own history

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

python/pep8 format changes

enforce YAML, build system format checks?

offer / encourage pre-commit hook usage (e.g. through this)