-
Notifications
You must be signed in to change notification settings - Fork 318
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sof_api: lmdk: Extraction of api headers for loadable modules #8365
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fwiw, I think git has a cmd line hint to help it detect file moves, but GH may not interpret it.
@@ -0,0 +1,240 @@ | |||
/* SPDX-License-Identifier: BSD-3-Clause */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I agree having an API directory for modules is good, but can we call it include/module/ ? This way all our modules would be including e.g.
#include <module/ipc4/base-config.h>
#include <module/module.h>
and so on. i.e. we make it clear this API is for modules and make it more obvious when new APIs are added if they are intended for baseFW or are intened for client modules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Idea behind it is to keep this files as an external header package and calling it sof_api doesn't leave place for mistake.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Modules include are limited only to include/sof_api directory, so its include will looks like:
#include <ipc4/base-config.h>
#include <module/generic.h>
From the sof perspective it is:
#include <sof_api/ipc4/base-config.h>
#include <sof_api/module/generic.h>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Idea behind it is to keep this files as an external header package and calling it sof_api doesn't leave place for mistake.
This is not going to work if headers are external to this repo, headers need to be local to this repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Modules include are limited only to include/sof_api directory, so its include will looks like:
I'm good with that. My issue is that sof_api
name is quite ambiguous i.e. API for SOF what ? all of SOF or just part of SOF. In this case it needs to be clear that this API is only for modules only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These headers will be kept in this repo for CI needs. If any changes will be required we will create headers release package for loadable modules and change api version number to keep on track changes. For that will have to create some kind of ABI script only for this cathalog.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Modules include are limited only to include/sof_api directory, so its include will looks like:
I'm good with that. My issue is that
sof_api
name is quite ambiguous i.e. API for SOF what ? all of SOF or just part of SOF. In this case it needs to be clear that this API is only for modules only.
sof_api because we are using module_api, component_api and that headers contains essential data structures for modules to be loaded. If naming is such a problem we can move them to lmdk/include
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The direction of travel is component api is deprecated and will be removed, we will only have module api for modules so this programming surface must be obvious for module developers. In the future we will have the following include directories (not showing IADK atm)
- src/include/module - all APIs used for modules
- src/include/sof - base FW apis, not used by modules.
- src/audio/<module_name>/ - local module private headers, used by module only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lgirdwood I will rename sof_api
to module
soon.
f3d4891
to
60b7191
Compare
Now that Zephyr supports loadable module is there a plan to use this feature with SOF? https://docs.zephyrproject.org/3.5.0/services/llext/index.html |
Yep, we are working on several fronts to provide
We should be able to have both methods usuable above via Kconfig. Your welcome to beta test :) |
Great. Thanks. Will test the new features with Cadence libraries. |
here's the current state #8180 together with zephyrproject-rtos/zephyr#62433 but it's still WiP |
@@ -14,7 +14,7 @@ | |||
#include <stdint.h> | |||
#include <rtos/string.h> | |||
#include <utilities/array.h> | |||
#include <adsp_error_code.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so now we have sof_api and iadk ?
Should not IADK go to sof_api as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the difference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cujomalainey IADK is an Intel C++ wrapper/extension to the base sof C module API that aligns with modules used on Windows today.
53082f4
to
9cb0a2e
Compare
@@ -14,7 +14,7 @@ | |||
#include <stdint.h> | |||
#include <rtos/string.h> | |||
#include <utilities/array.h> | |||
#include <adsp_error_code.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the difference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very hard to follow with massive amount of code moved around. I don't have any showstoppers though. I did add a few editorial comments. The copyright updates are really problematic, one should NEVER REMOVE copyright years from source files and this PR does this in a massive scale. But given we use git to track the history in SOF, this is probably not a blocker if everyone else is happy. I do worry about the work to maintain this series. Couldn't we merge parts of this in pieces to get progress. Having this kind of massive series long in review is taking lot of time both from you the authors as well as everybody reviewing.
a6254d2
to
cab4bec
Compare
@kv2019i I restored copyright years. From my perspective, it was just cutting parts of the files and pasting them into a new files. I thought that the review in this case would be a formality. In the future, in a similar situation, I will break it into a series of atomic PRs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @softwarecki , good for me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm good with 99%, but we cant have conditional code in the structures as a marker for PRIVATE and public APIs, this will mean different ABI for different users. We should use a comment here whilst any cleanup is in progress.
uint32_t period_bytes; /** pipeline period bytes */ | ||
|
||
/* Fields below can only be accessed by the SOF */ | ||
#ifdef SOF_MODULE_API_PRIVATE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this new, wont it change the ABI if its defined for some users and not others ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lgirdwood This symbol is defined in the file included by sof. Loadable modules should not define it and nor refer to this part of the structure. This structures should be divided in a future so sof can keep their private fileds in a different structure. It will take a lot of work and will require a lot of changes. Would it be enough for now to add a comment that this is a temporary solution until these fields are separated into a new structure?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the comment need to be very visible and explain the roadmap forwards. That way its really obvious to everyone working on modules.
@softwarecki wrote:
Note for future: Yes, this generally applies and this is how I would treat a PR like you describe. But for this to work well, the PR needs to be doing just this. If you mix monotonic changes (like renames or moves) with small functional changes, then either you need to explain that very well in the cover letter ("one functional commit and rest are just renames"), or otherwise you will freak out the reviewers when they browse through the code and note changes that go beyond the simple. I mean this PR has also not so trivial changes, like the changes to header inclusion dependencies and changes to lmdk build rules. So when title says "api extraction", but I see commits that go beyond this, then this is no longer a trivial PR. This is ok as well, but just requires more time to review each iteration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the future, in a similar situation, I will break it into a series of atomic PRs.
I don't see why it's too late. You never have to submit all your local commits all at once. I git push myfork HEAD~5:refs/heads/notEverythingAllAtOnce
all the time, keeping the last 5 commits (as an example) for later. The later commits provide more, local test coverage for the submitted commits.
You can still do this now.
Sometimes I push a second invisible/draft PR for even more test coverage (this is what I did in #8495)
https://docs.zephyrproject.org/latest/contribute/contributor_expectations.html#defining-smaller-prs
EDIT: smaller PRs also provide more test coverage of individual commit and make it much easier to catch, understand and deal with regressions.
EDIT: smaller PRs also reduce conflicts and make their resolution easier:
sink_api.c | ||
) | ||
else() ### Not Zephyr ### | ||
add_local_sources(sof |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can simplify this after #8494 is merged. Good enough for now.
Removed unused includes from a header files. Signed-off-by: Pawel Dobrowolski <pawelx.dobrowolski@intel.com>
Moved header files to the module directory to separate an shared interface used by sof and native loadable modules. Signed-off-by: Adrian Warecki <adrian.warecki@intel.com>
Moved header files to the module directory to separate an shared interface used by sof and native loadable modules. Signed-off-by: Adrian Warecki <adrian.warecki@intel.com>
Moved header files to the module directory to separate an shared interface used by sof and native loadable modules. Signed-off-by: Adrian Warecki <adrian.warecki@intel.com>
Moved header files to the module directory to separate an shared interface used by sof and native loadable modules. Signed-off-by: Adrian Warecki <adrian.warecki@intel.com>
Moved header files to the module directory to separate an shared interface used by sof and native loadable modules. Signed-off-by: Adrian Warecki <adrian.warecki@intel.com>
Extracted struct sof_audio_stream_params and enum sof_ipc_frame definitions get_sample_bytes, get_sample_bitdepth and get_frame_bytes functions to a new files in the module directory to separate an shared interface used by sof and native loadable modules. Signed-off-by: Adrian Warecki <adrian.warecki@intel.com>
Moved header files to the module directory to separate an shared interface used by sof and native loadable modules. Signed-off-by: Adrian Warecki <adrian.warecki@intel.com>
Use of a separated module headers when building native loadable libraries. Signed-off-by: Adrian Warecki <adrian.warecki@intel.com>
Added building a static library containing common functions for modules provided by sof. Native loadable modules are statically linked to it. Signed-off-by: Adrian Warecki <adrian.warecki@intel.com>
@lgirdwood @marc-hb @lyakh |
I separated some of the headers into a separate modules directory. They will be shared between sof and native loadable modules.