Support Extended Modversions #270
Conversation
|
Noticed these issues while reviewing changes: #272 Since they are already in master, I have created a new PR. No need to slow down functional review if there are bugs in the underlying base. ;) These PRs should be kept in sync, depending which one is merged first. |
| 0x........ debugfs_create_dir | ||
| 0x........ debugfs_create_file | ||
| 0x........ __x86_return_thunk | ||
| 0x........ module_layout |
There was a problem hiding this comment.
@stoeckmann / @evelikov do you see a way to also test the extended format? Maybe we could:
- build the module with that config set
- extract the 2 sections and save it, base64-encoded
when building the kmods, we just add the sections to one of the modules with objcopy --add-section. Thoughts?
maurer
force-pushed
the
extended-modversions
branch
2 times, most recently
from
aba1927 to
c7c2ab5
Compare
Makes `kmod_elf_get_dependency_symbols` dispatch to `kmod_elf_get_modversions` rather than open-coding the same version extraction. This helps avoid duplicating logic, especially as we add support for the extended format. Link: kmod-project#270 Signed-off-by: Lucas De Marchi <[email protected]>
In order to allow longer names, the kernel is taking a new MODVERSIONS format option which stores the names in a strtab-like section and the crcs in an array-like one. This patch makes `kmod_elf_get_modversions` use either format, preferring the new one where present. Signed-off-by: Matthew Maurer <[email protected]> Link: kmod-project#270 Signed-off-by: Lucas De Marchi <[email protected]>
We can't test actual CRC values, because they may vary depending on kernel configuration. We can ensure the correct symbol names show up though. Signed-off-by: Matthew Maurer <[email protected]> Link: kmod-project#270 Signed-off-by: Lucas De Marchi <[email protected]>
lucasdemarchi
force-pushed
the
extended-modversions
branch
from
c7c2ab5 to
3eaf725
Compare
|
@maurer the last commit with the additional testsuite patch breaks it because we don't have a way to test with that. I tried to replicate your env, but couldn't: |
|
It looks like debian:unstable worked, but nothing else did. It's re-using an existing test module and just checking other properties on it, so this most likely means that the test is failing because kernel doesn't even have As far as replicating my setup, the patches have landed upstream, so just grab a recent release and you'll see it, no need to |
how would you check for it? Running kernel may not be the tested kernel so it would require to check $KDIR/.config. I think what we can do is to skip if the error is due to ENODATA instead of checking the config. We can do it easily with libkmod, but not easily with modprobe --dump-modversions.
ok, thanks. |
Makes `kmod_elf_get_dependency_symbols` dispatch to `kmod_elf_get_modversions` rather than open-coding the same version extraction. This helps avoid duplicating logic, especially as we add support for the extended format. Link: #270 Signed-off-by: Lucas De Marchi <[email protected]>
In order to allow longer names, the kernel is taking a new MODVERSIONS format option which stores the names in a strtab-like section and the crcs in an array-like one. This patch makes `kmod_elf_get_modversions` use either format, preferring the new one where present. Signed-off-by: Matthew Maurer <[email protected]> Link: #270 Signed-off-by: Lucas De Marchi <[email protected]>
A companion to the
EXTENDED_MODVERSIONSkernel patch series, this PR adds support forlibkmodto access the new modversions format when present, falling back to the original format otherwise.Tested with
KDIR=override selecting a kernel withEXTENDED_MODVERSIONS=yandBASIC_MODVERSIONS=nenabled with the series above in addition to a normal existing kernel.