Skip to content

[RFC] [FEATURE] Refactor host/testbench #1229

@jajanusz

Description

@jajanusz

Is your feature request related to a problem? Please describe.
Current host/testbench build is bad, because of at least these few reasons:

  1. Naming it host is a bit of lie, you can build it for xtensa and run testbench with xt-run (f.e. to test performance of comps implementations).
  2. We build 2 things in the same tree - troublesome, messy especially for new developers. We have src/ folder that one time builds fw and another testbench.
  3. Tightly coupled things that should be talking only via library api, it's hard to notice what we should export, ugly cuts with #ifdef CONFIG_HOST etc.
  4. There is no host arch at all. Name it x86/arm or even generic is better to indicate that implementation of these things may be provided f.e. by compiler std libs.
  5. Platform headers split unneccesarily into platforms/ and library/.
  6. Host-specific headers are in public/project wide include folder, when they don't need that level of visibilty.

Describe the solution you'd like

  1. Instead of host build we should just have a library build that creates shared libs with parts of fw that can be used by some apps. So, from the code under src folder, instead of being able to build FW or testbench, we will be able to build FW or library with components that can be used f.e. by testbench. Libs we are going to build initially include:
    • Core lib with components architecture, init, pipeline, buffers.
    • Plugin-like lib for each component, f.e. libvolume.so, libsrc.so, etc.
  2. Arch host will be renamed to generic that will be default for library build.
  3. All code related to testbench will be moved to testbench folder (from src) and will just be user of sof library.

Describe alternatives you've considered
I'm open to suggestions. I know there may be better ways to solve some problems, but it looks like a good start to mark some boundaries between parts of the project and decrease spaghetti-code factor 🍝

Metadata

Metadata

Assignees

Labels

enhancementNew feature or requestneed infoFurther information is requested

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions