GNU Radio 4.0 Preliminary Code Review: Difference between revisions
Jump to navigation
Jump to search
(Created page with "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....") |
No edit summary |
||
(5 intermediate revisions by 2 users not shown) | |||
Line 3: | Line 3: | ||
; License | ; 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) | : 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 | ; Build System | ||
Line 11: | Line 14: | ||
: 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 | |||
* 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 | ||
Line 32: | Line 35: | ||
** Less scheduler "hints" | ** Less scheduler "hints" | ||
** Self contained work() function | ** Self contained work() function | ||
; Python Blocks | |||
: block implementations | |||
: arbitrary blocks | |||
; Block Autogen | ; Block Autogen | ||
Line 37: | Line 44: | ||
: jinja templates | : jinja templates | ||
: create_{mod,block} scripts | : 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 | ; Kernel Library | ||
Line 50: | Line 61: | ||
; Benchmarking | ; Benchmarking | ||
: What to include in-tree | : What to include in-tree | ||
; GRC | |||
: Changes needed to support 4.0 features | |||
: Plan to move out of tree?? | |||
: Start with QT port or off established GTK GRC? | |||
; 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 [https://pre-commit.com/hooks.html this]) | |||
; Out-of-Tree / Ecosystem | |||
: example OOT project | |||
: modtool (successor? Extension? BW compat?) | |||
: deb/rpm/conda packaging as default component in OOTs |
Latest revision as of 16:37, 6 April 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)
- 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
- Python Blocks
- block implementations
- arbitrary blocks
- 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??
- Start with QT port or off established GTK GRC?
- 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)
- Out-of-Tree / Ecosystem
- example OOT project
- modtool (successor? Extension? BW compat?)
- deb/rpm/conda packaging as default component in OOTs