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
