Skip to content

lkl: remove string functions duplicate implementation #590

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

Merged
merged 2 commits into from
Apr 13, 2025

Conversation

tavip
Copy link
Member

@tavip tavip commented Apr 9, 2025

Now that we have the ability to set kernel config options per host built we can avoid duplicating the implementation for string functions that may be provided by the host (e.g. memcpy, memset).

Fixes: #582

@tavip tavip requested review from thehajime and rodionov April 9, 2025 00:47
Copy link

@ddiss ddiss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like a nice cleanup. One concern: lkl_ops is set at run-time, so we could have a "posix" host call lkl_init() with e.g. lkl_host_operations.memset = NULL.
It looks as though the main reason for using run-time ops instead of build-time is for overloading the print() hook, so perhaps we could switch the API to use build-time ops and provide print() hooks elsewhere? Another (simpler) option would be to fail lkl_init() if any of the mem ops are NULL alongside CONFIG_LKL_HOST_MEM*=y.

@tavip
Copy link
Member Author

tavip commented Apr 10, 2025

One concern: lkl_ops is set at run-time, so we could have a "posix" host call lkl_init() with e.g. lkl_host_operations.memset = NULL.

Good catch!

It looks as though the main reason for using run-time ops instead of build-time is for overloading the print() hook, so perhaps we could switch the API to use build-time ops and provide print() hooks elsewhere?

The original intent was to have LKL distributed as a shared library and allow external applications to override run-time ops. In practice, because we lack support for modules the former is not yet achievable.

On one hand having runtime host ops gives more flexibility to applications, on the other hand built-time host ops would probably give a nice performance boost.

Another (simpler) option would be to fail lkl_init() if any of the mem ops are NULL alongside CONFIG_LKL_HOST_MEM*=y.

Yes, this is a good option while we discuss more built-in vs run-time host ops. I'll send another version to add these checks.

Copy link
Member

@thehajime thehajime left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, would wait for @rodionov 's input.

@@ -6,6 +6,25 @@ int lkl_init(struct lkl_host_operations *ops)
{
lkl_ops = ops;
Copy link

@ddiss ddiss Apr 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please put this after the config checks. I don't think lkl_ops should be initialized on failure...
(edit: kasan_init() failure should probably leave it unset too, but that can be done separately)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, thanks !

return -1;
}
#endif

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

coding-style.rst encourages avoiding #ifdef CONFIG_... outside of header files. How about something like:

        if ((IS_ENABLED(CONFIG_LKL_HOST_MEMCPY) && !ops->memcpy)
         || (IS_ENABLED(CONFIG_LKL_HOST_MEMSET) && !ops->memset)
         || (IS_ENABLED(CONFIG_LKL_HOST_MEMMOVE) && !ops->memmove)) {
                lkl_printf("unexpected NULL lkl_host_ops memory I/O call\n");
                return -1;
        }

The compiler should still be able to optimize it out for non-posix hosts.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, thanks!

@rodionov
Copy link

Thank you, @tavip! lgtm pending @ddiss's comments.

@rodionov rodionov closed this Apr 10, 2025
@rodionov rodionov reopened this Apr 10, 2025
@tavip tavip force-pushed the lkl-rm-str-dup branch 2 times, most recently from db68edc to f4dbc3c Compare April 10, 2025 23:30
Copy link

@ddiss ddiss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @tavip ! Looks good

@@ -4,6 +4,15 @@

int lkl_init(struct lkl_host_operations *ops)
{
int ret;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: ret is unused

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed, thanks @ddiss !

tavip added 2 commits April 12, 2025 18:42
Now that we have the ability to set kernel config options per host
built we can avoid duplicating the implementation for string functions
that may be provided by the host (e.g. memcpy, memset).

Signed-off-by: Octavian Purdila <[email protected]>
Check lkl_init for failures. Print the log buffer in case of failures,
to make debugging easier.

Signed-off-by: Octavian Purdila <[email protected]>
@tavip tavip merged commit 75133a5 into lkl:master Apr 13, 2025
13 of 14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove string function code duplication
4 participants