Hi WanWizard,
The module ko file loads on boot, which makes the proc nodes available. Why is the name of the module relevant? And I thought it was decided that proc nodes for multiboot images was a bad idea?
Did I miss something?
Perhaps I missed something. I thought that the ko file on each slot was to be accessed to get information about the image on slots other than the currently running image in the current slot. That is why concern was shown earlier about the file being located in a path that contains a dynamic value (of the image's kernel version).
Regards,
Ian.
Ian, I have no idea why you want to make this complicated. There is no need to know the kernel version folder name to access "modinfo" details of that file.
e.g.
root@vuultimo4k:~# python
Python 2.7.16 (default, Jan 3 2020, 14:39:48)
[GCC 9.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import subprocess
>>> import glob
>>>
>>> for f in glob.glob('/lib/modules/*/kernel/drivers/openvision/openvision.ko'):
... print f
...
/lib/modules/3.14.28-1.12/kernel/drivers/openvision/openvision.ko
>>>
>>>
>>> p = subprocess.Popen("modinfo %s" % f, stdout=subprocess.PIPE, shell=True)
>>> (output, err) = p.communicate()
>>>
>>> print output
filename: /lib/modules/3.14.28-1.12/kernel/drivers/openvision/openvision.ko
description: Open Vision information
author: Open Vision developers
license: GPL
depends:
vermagic: 3.14.28-1.12 SMP mod_unload ARMv7 p2v8
>>>
>>>
Storing that data in the module description is already hack. Lets not add another hack to make the first hack "better".