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
component: move comp_copy from header file to source file #6344
component: move comp_copy from header file to source file #6344
Changes from all commits
d62b074
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.
@btian1 why will cmocka tests require comp_copy() On the contrary the comp_drv interface will eventually be deprecated for all 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.
because each cmocka module unit test need comp_copy, once move it from component_ext.h to component.c, cmocka need component.c to make comp_copy real.
regarding remove comp_drv, that's another topic for me, let's keep current solution, I can't wait until comp_drv disappearred.
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.
Yes, Marc, this is correct, regarding the #ifndef ZEPHYR, I will change it in #6322(since perf_cnt.h need change as well), after this merged, #6322 should be based on ipc4+zephyr, ipc4 need this change as must, so I have to wait for this change merge first, then modify #6322.
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.
There are empty definitions of
perf_...()
provided in the header for a configuration with CONFIG_PERFORMANCE_COUNTERS undefined, so it not necessary to use #if-s inside the caller's code. Also the code would be easier to maintain when number of #if-s is limited.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.
Why only mixer component needs these additions? Is there something in other components or their unit tests that helps to avoid to do these.
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 because mixer cmocka test need this API for test purpose.
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 think this should be in component.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.
there is no component_ext.c for source file, so component.c can cover component_ext.h and component.h both.
and if move to component.h will cause much more changes, a lot of component_ext.h include will change to component.h.
Agree?
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.
component_ext.h contains all inline functions, no function prototype in it. while component.c and component.h are .c/.h pair.
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.
void sys_comp_init(struct sof *sof);
it have, also defined in component.c
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.
It seems quite confusing indeed. Some prototypes like comp_get_copy_limits() are in component.h while others like comp_new() are in component_ext.h. Given other copy relate functions have prototypes in component.h, I'd put comp_copy() there as well. @ranj063 @juimonen do you happen to recollect the history?
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 searched #include <sof/audio/component_ext.h> under SOF directory, it have nearly 50 place to include, if move it to component.h, it will cause much more source file to change.
I don't know history about component.h and compont_ext.h, but currently, they have same component.c source file.
even check component.h, it is mixed with macro, inline, prototype.
If we really want to change, I would suggest discuss first, then raise an CR to merge(or re-arrange) two header files
currently, suggest to keep, since component_ext also have prototype declaration, Agree?
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 would not be pleasant but it's not the end of world either: it's only a one-line change in each file so this would not break
git
much. If this is really the best choice then don't be afraid to do it.Most projects have some messy
#include
s that no one really cares about... until someone tries to move something exactly like as you're doing here; it's typical. Sometimes this can trigger some#include
cleanup and that's usually a good thing.Note: I do NOT know whether it's the best choice! Discuss and make sure first. Considering how longer and longer this thread is getting, a call should help.
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.
@btian1 I think keeping the comp_copy() declaration is component_ext.h is fine. All the other ops' declaration or definition are in this file. So I see no objection here
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.
Github's browsing features are very user-friendly. Sometimes I drop
tig
and switch to the web browser instead!...
(top right corner) -> View File -> Blame -> line 1 ->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.
No, it should not. It is a little helper function that hides comp driver/device details, called by the infrastructure. While the component.h was intended to declare things relevant for component implementors, see the commit message @marc-hb mentioned in the comment above. component.h had been overloaded and unreadable before component_ext.h was created to separate internal non-api things. Not sure if merging back is a good idea.