On Mon, Jul 01, 2024 at 12:51:50PM GMT, Valerii Chernous -X (vchernou - GLOBALLOGIC INC at Cisco) wrote:
Hi Nicolas,
It sounds to me, as if you would like to auto-generate modprobe.d/ files
for your platforms at boot time and implement the pre-loading of some
modules before some others with common modprobe.d syntax (e.g.
'install', cp. modprobe.d(5)). But you probably evaluated that before
implementing your patches?
Some kind but not exactly. I try to provide method to avoid regenerating
modules deps db during runtime
If your module load order is just platform dependent, I do not yet
understand, why (possibly boot-time dynamic) depmod.d configuration is
not sufficiently flexible enough. I probably have missing some
important point.
Device filesystem mounted as readonly to reduce security riscs so using
depmod during boot time is restricted
depmod is never ever used during boot time... we should be able to boot
without even have depmod and even without modprobe (since libkmod used
by systemd should already have everything needed).
It looks like you have several modules exporting kind of duplicated
symbols and want something in runtime to disambiguate which module
should be loaded. I need an example to understand this... it's sounding
more like the chosen abstraction to have duplicated symbols (rather than a
xxx-common.ko module) is the main thing that could be changed without
adding complexity to module dep resolution.
Lucas De Marchi
I strongly support Lucas' request for a cover-letter.
Probably, it will be a good idea to prepare test repo with couple of simple
modules to demonstrate what patchset do
Kind regards,
Nicolas
Thank you Nicolas for review :)
Best regards,
Valerii
________________________________________
From: Nicolas Schier <n.schier@xxxxxx>
Sent: Monday, July 1, 2024 1:33 PM
To: Valerii Chernous -X (vchernou - GLOBALLOGIC INC at Cisco)
Cc: Lucas De Marchi; linux-modules@xxxxxxxxxxxxxxx; xe-linux-external(mailer list); Lucas De Marchi
Subject: Re: [MODALTS v0.1 4/4] add modules deps alternatives description
On Mon, Jul 01, 2024 at 09:23:03AM +0000, Valerii Chernous wrote:
>On Fri, May 10, 2024 at 04:21:28AM GMT, Valerii Chernous wrote:
>>Cc: xe-linux-external@xxxxxxxxx
>>Cc: Valerii Chernous <vchernou@xxxxxxxxx>
>>Signed-off-by: Valerii Chernous <vchernou@xxxxxxxxx>
>>---
>> README.deps.alternatives.txt | 40 ++++++++++++++++++++++++++++++++++++
>> 1 file changed, 40 insertions(+)
>> create mode 100644 README.deps.alternatives.txt
>>
>>diff --git a/README.deps.alternatives.txt b/README.deps.alternatives.txt
>>new file mode 100644
>>index 0000000..9ad3ce5
>>--- /dev/null
>>+++ b/README.deps.alternatives.txt
>>@@ -0,0 +1,40 @@
>>+Modules alternatives feature allow to calculate dependency alternatives
>>+during build time and aviod to regenerate modules db into runtime
>>+
>>+To enable deps alternatives calculation use "-D" flag with depmod,
>>+it will create indexes modules.alternatives and modules.alternatives.bin
>>+This indexes will be used by modprobe in runtime
>>+By default modprobe will load first(primary/major) dependency from list
>>+If it required to load alternative module, it should be done manually before
>>+loading main modules set.
>>+For example systemd service that detect platform type can load required platform
>>+modules and after it run main device initialization
>>+In case when alternative module loaded, modprobe detect this and skip to load primary
>>+dependency
>>+
>>+modules deps alternatives generation basic algorithm description
>>+1. Load modules information(imported/exported symbols)
>>+2. Find depended symbol alternatives(create list available symbols
>>+ alternatives instead of storing last one)
>>+3. Choise primary/major alternative per depended symbol correspond to
>>+ build time dependency(build time deps getting from module info section)
>>+4. Create a list of dependency modules alternatives correspond to next rule:
>>+4.1 All modules alternatives for module dependency should provide all symbols
>>+5 Store modules alternatives index(modules.alternatives) as key:value where
>>+key is a pair depended#_#primary_depency,
>>+value is list of all modules that provide all symbols from primary_depency
>>+for depended module
>>+
>>+Note:
>>+Current implementation/algorithm doesn't cover variant where requred symbols
>>+from primary deps provided by more that one modules. Exporting all symbols in
>>+alternative depency that used by depended module from primary_depency is
>>+mandatory!
>>+
>>+Note:
>>+modules.dep index different for standard/basic and modules alternatives algorithms
>>+modules.dep for modules alternatives algorithm contain only direct dependencies and
>>+full dependency list will be calculated into runtime correspond to preferred alternative.
>>+modules.dep for standard/basic algorithm contain full dependency list for module and
>>+can't be changed during runtime without rebuild database via depmod
>well... this kind of explains the what, but still no clue on why.
>If multiple different modules are providing the same symbol, then they
>are doing things wrong.
>If there are multiple variants of the same module (again, is this about
>external modules?), then I see no advantage to delay the decisions from
>depmod-time to modprobe-time. Just setup your depmod.d configuration.
>Also end users have not visibility on a README.deps.alternatives.txt
>file. Documentation in kmod is kept on man pages.
>Lucas De Marchi
First at all, thank you for review, Lucas.
Let me try to explain feature more:
1. You are correct, feature tested on external modules
2.
>If multiple different modules are providing the same symbol, then they
>are doing things wrong.
Modules exported the same api(the same functions) and on my opinion it's ok
and kernel process normally different modules with the same exports. One major
restriction is only one module with the same symbols can be loaded on the same
time but it's ok in my case(as I described, in my case, it's per platform
modules and devices with different hardware using the same software image).
3.
>If there are multiple variants of the same module (again, is this about
>external modules?), then I see no advantage to delay the decisions from
>depmod-time to modprobe-time. Just setup your depmod.d configuration.
It can be different variant of the same module but maybe not. For example it
can be cryptography modules. Modules provide the same api but implementation
of api is totally different and depend on specific hardware. With modules
alternatives feature it's easy to use this kind of modules. You can use
required alternative for specific hardware and all depended modules can use
external functions directly without any wrappers or "if" statements to resolve
dependencies.
With using depmod.d configuration it's possible to choose primary alternative
into build time but in my case required alternative is unknown during build time,
it will be known only into runtime. In this case it required to regenerate
modules db into runtime and I try to avoid this.
It sounds to me, as if you would like to auto-generate modprobe.d/ files
for your platforms at boot time and implement the pre-loading of some
modules before some others with common modprobe.d syntax (e.g.
'install', cp. modprobe.d(5)). But you probably evaluated that before
implementing your patches?
If your module load order is just platform dependent, I do not yet
understand, why (possibly boot-time dynamic) depmod.d configuration is
not sufficiently flexible enough. I probably have missing some
important point.
I strongly support Lucas' request for a cover-letter.
Kind regards,
Nicolas
