-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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
LLEXT dependencies: add support for linking between LLEXT objects #77473
Conversation
Test zephyrproject-rtos/zephyr#77473 Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Test zephyrproject-rtos/zephyr#77473 Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Test zephyrproject-rtos/zephyr#77473 Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
@lyakh sorry for marking this as ready for review, I misclicked in the GitHub mobile app. Apologies for the noise. |
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.
Looks mostly reasonable to me, some oddities that are maybe caused by using llext_iterate when perhaps instead a different approach would avoid some strangeness
Should fix the formatting issues otherwise misra checks will fail and someone just fixed many issues in the tree related to misra styling.
@@ -111,6 +114,8 @@ struct llext { | |||
|
|||
/** Extension use counter, prevents unloading while in use */ | |||
unsigned int use_count; | |||
|
|||
struct llext *dependency[LLEXT_MAX_DEPENDENCIES]; |
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 could use a doc string
Test zephyrproject-rtos/zephyr#77473 Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
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.
Neat piece of work!
A few comments from me, but otherwise looks pretty solid:
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.
Nit: this sounds prone to race conditions - but the whole subsystem is, anyways, as struct llext
lacks a lock... This is well outside PR scope though 😄
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.
Agree with all comments, I'm late to the party 🙂
Otherwise LGTM as well! 👍 Thanks!
Remove a loop counter, that isn't actually used for anything. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Currently LLEXT has two ways to export symbols: EXPORT_SYMBOL() to exort symbols from the main firmware to extensions LL_EXTENSION_SYMBOL() to export symbols from extensions but it is possible to write code, that needs to export symbols regardless of whether it is built into the main image or an extension. And in fact there's no real need in two distinct macros - we can use one for both cases and recognise at build time which direction exporting is happening. This patch extends EXPORT_SYMBOL() to also work from extensions. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Replace LL_EXTENSION_SYMBOL() with EXPORT_SYMBOL() in all tests and samples. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
LLEXT objects can also export symbols for use by other such objects. That means, that when linking an LLEXT object we have to look for unresolved symbols in previously loaded objects too. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Using the immediate logging option from LLEXT modules requires one more symbol export. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
When deciding which sections to group together, only the low 3 section attribute bits are relevant, ignore the rest. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
99679e0
to
89d27f7
Compare
When an LLEXT object uses symbols of another such object, it depends on it. Such dependencies have to be tracked to prevent their accidental unloading. Ideally we should be able to track arbitrary numbers of such dependencies, but this is a bit difficult. In this first implementation we use a fixed-size array, currently consisting of 8 entries. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
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.
LGTM, thanks for this!
Just mentioning a tiny refactor issue, maybe fix it if you ever have to rework commits.
if (link_addr == 0) { | ||
/* Try loaded tables */ | ||
struct llext *dep; | ||
|
||
link_addr = (uintptr_t)llext_find_extension_sym(name, &dep); | ||
if (link_addr) { | ||
llext_dependency_add(ext, dep); | ||
} | ||
} | ||
|
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.
Very minor nit - if you ever have to refactor anything: this bit of code is added in the last commit, which only deals with dependency tracking. Similar to what happens for Xtensa, it could be split between the commit that introduces the actual lookup and the one adding tracking.
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.
LGTM.
Nit: I feel like llext_find_extension_sym
would be a more fitting name for what we currently call llext_find_sym
, and vice-versa... just food for thought, changing the API is not in scope for this PR 😄
#77738 adds a (draft but should be already working) test for this new functionality, which will be finalised and released for review and merging once this has been merged |
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.
Very nice set of changes
@@ -62,6 +62,9 @@ enum llext_mem { | |||
struct llext_loader; | |||
/** @endcond */ | |||
|
|||
/* Maximim number of dependency LLEXTs */ | |||
#define LLEXT_MAX_DEPENDENCIES 8 |
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 should be a Kconfig, not a blocker but would be good to see a follow up for
Added dnm given @lyakh's initial comment indicating this was a draft, to avoid accidental merge. Please confirm you'd like to have this merged. You (or anybody else) is welcome to remove the dnm. |
Test zephyrproject-rtos/zephyr#77473 Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
This adds support for exporting symbols between extensions while building dependencies based on such symbol references