-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
kernel: Change the prototype of k_thread_access_grant. #12253
kernel: Change the prototype of k_thread_access_grant. #12253
Conversation
Codecov Report
@@ Coverage Diff @@
## master #12253 +/- ##
==========================================
+ Coverage 48.2% 48.25% +0.05%
==========================================
Files 294 294
Lines 44192 44195 +3
Branches 10603 10608 +5
==========================================
+ Hits 21302 21326 +24
+ Misses 18624 18602 -22
- Partials 4266 4267 +1
Continue to review full report at Codecov.
|
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... technically this is an API change and not legal without deprecating the old call (unless the memory protection stuff is officially "unstable" or something and can still change?). Keeping the same name but changing the behavior in subtle ways (i.e. making the old required trailing null into a crash condition!) seems like a bad idea if we expect any code to be using this in the wild.
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.
Minor changes, the patch fixes the problem with variadic parameters.
include/misc/util.h
Outdated
* With one fixed argument and changing 2nd argument. | ||
*/ | ||
|
||
#define _rep_0(_fn, f, ...) |
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.
_rep_0(_fn, f)
?
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.
start these macros with underscore will violate rules 21.5 and 21.6, though this will be addressed in other fix, would be nice we introduce it with the right namespace like is described in #9882
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.
oh my bad, I forgot to take care of that. Fixed that.
@AdithyaBaglody please add the misra-c rule in the commit message. |
This new macro will be able to do FOR_EACH with a fixed argument. This fixed argument will always be called as the 2nd argument to the function call(_fn). Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
This API was using variable number of arguments. Which is not allowed according to misra c guidelines(Rule 17.1). Hence making this API into a macro and using the util macro FOR_EACH_FIXED_ARG to get the same functionality. There is one deviation from the old function. The last argument shouldn't be NULL. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
With the new implementation we do not need a NULL terminated list of kobjects. Therefore the list will only contain valid entries of kobjects. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
8c6a578
to
35ca98d
Compare
@andyross Actually, this doesn’t break even if we have a NULL in there. I changed everywhere in our tree because the restriction no longer applies to this API. So for instance, if someone has been using this API outside our tree, they will not face any crash or failure. |
This API was using variable number of arguments. Which is not
allowed according to misra c guidelines. Hence making this API
into a macro and using the util macro FOR_EACH_FIXED_ARG to get
the same functionality.
There is one deviation from the old function. The last argument
shouldn't be NULL. If it is NULL the code will fault.