Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
library_manager: Update module load flow #8544
library_manager: Update module load flow #8544
Changes from all commits
029b922
6fe60c5
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 skips .bss, so effectively you made a loop for 2 elements. Should we go a step further and integrate .bss here too by either copying data for .data and .text or clearing the buffer for .bss?
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.
@lyakh The .bss section is handled differently. Its size is divided by the maximum number of module instances and only the selected fragment for a given instance is mapped.
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.
well, that special .bss handling seems strange to me - it's too ad-hoc IMHO. This means, that you cannot have the same file used both as a loadable module and built-in, because its .bss will be handled differently. Besides it's too special - developers would need to think about it every time they put something in .bss. We discussed this with @pjdobrowolski briefly and maybe we can and should drop that behaviour.
And if we don't and we keep .bss out and only handle .text and .data here, we effectively get a loop over three elements to then throw away one of them, leaving a loop over two iterations - you could just keep it as is unfolded.
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.
@softwarecki @lyakh any update here, should we put a big inline comment here spelling out this difference and its expected behavior from ROM i.e. its done for current compatibility reasons
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.
any communication between modules, build-in or loadable should be done by using native-system-services. I'm no sure if making shared bss is good practice for such behavior. Especially if we load and unload modules on fly, what will happen with common bss? Each module will leave it own stuff in there until we will have an overflow/
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.
DSP has restricted 3MB of ram which is shared between modules. BSS is defining how much of we use. Can you explain me how removing BSS sections from elf will improve working on such small space?
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.
@lyakh You wrote: "This means, that you cannot have the same file used both as a loadable module and built-in...". Where you see use case to have the same code used as loadable and built-in at the same time? I think we do loadable to not have given module built into base FW all the time.
Another think, there are other reasons for having separate .bss section for each module.
One is backward compatibility with reference FW design.
The other even more important is possibility to use in the feature some memory protection features. Mixing up the module .bss with base FW general .bss section will block us from introducing such solution.
The third reason is the debuggability of base FW with presence of external modules. If we mix up the memory spaces, tracking any failures will be more difficult since external modules could corrupt base FW data.
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.
@pjdobrowolski @jxstelter I think there's some confusion here. I'm not proposing to remove .bss or to share .bss between modules or anything special of that kind. I just propose to do what C does: you program
and it's placed in .bss and it's available there to that file (because it's
static
). Or you have a globaland it's also in .bss and accessible globally. In all cases there's exactly 1 copy of that object. What I don't understand why loadable modules are linking those objects with module instances. That means, that e.g. if you make volume a loadable module. And you activate 3 pipelines and each of them has a volume component in it so you have 3 instances. So then you give to each instance i.e. to each volume component in each pipeline a separate part of that .bss, i.e. a part of those objects. I understand why it is done, but I don't find this a good idea. It is done to "emulate" a poor-man allocation, so you want to put something like
in those modules and then give each instance one of those objects. But I don't find that a good approach. I think it's confusing and misinterpreting the meaning of the ELF .bss section
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.
If you would look more carefully in history of commits, you would find out, that connecting .bss with instances was introduce much before idea of "poor-man allocation".
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.
ok, so I think we probably need to make relationship between bss and instances more visible with inline comments in the code here, this way we can avoid any misunderstandings as we continue and add logic for services API and IADK modules.