Conversation
If module subdirectories are versioned, we need to search a bit harder for potential update candiates as the name of the module subdirectory differs. We therefore search all weak-updates subdirectories of the $krel kernel for a module module matching the same name (taking into accout different compressions). Should we find multiple modules that match (which should not happen!) we flag this but continue regardless. This way, the first element in the list will be taken as the potential update candidate. Signed-off-by: Egbert Eich <eich@suse.com>
|
Why does the /kmp/ need to be added? Shouldn't modules installed in /usr/lib/modules/nvdia-G04-175.25 already get scanned for modules? If not why not? |
Please see my answer in #121 (comment) . |
That is completely irrelevant to the question. |
I beg you pardon? And no, |
|
I can't read your mind. I do not know what is in that /kmp directory. So your design is to prepend /kmp to the kernel version when installing KMPs. And my question is why do that instead of installing under a directory named after the KMP. And yes, it is not clear why merely prepending /kmp is more likely to work than installing in a completely arbitrary directory under /lib/modules. |
We need to do both:
Both are addressing a totally different issues. The first one (ie. 1. above) is explained in #121 (comment). |
|
I still don't understand, at all. How does inserting /kmp/ help anything? How do you get if in your design you do not use multiversion, and as a result you can only have one nvidia-open-driver-G06-signed? Why removing |
Where do I say, this is for a design without multiversion? I've been pointing out, that you will need all this - possibly more - to fix multiversion.
Once you install a package that's been built without |
|
|
Nor in |
You mean like |
|
But why not use this path that makes it clear what is installed in favor of the obscure kmp/ which also ties the installed modules to the specific implementation detail of using KMP as oppsed, say, DKMS? |
Why would Is Where would the kernel version go in what you suggest?
|
|
or The point is that people intentionally installed the nvidia package, they don't care if it was delivered through KMP or DKMS, and very few people actually know what that is. Putting the installation method before what is installed needlessly obfuscates what is installed. DKMS does not actually work correctly on (open)SUSE but before Linux version 6 the nVidia modules were installed through some DKMS-like method without actually using DKMS which needlessly rebuilt the module for every kernel. If it installed the module to a separate directory and used wm2 it could skip most builds, and DKMS could too if it is ever integrated. |
e4t
force-pushed
the
sles15-sp7-alternative-module-path
branch
from
1e3a4c2 to
ed01225
Compare
|
I see what is wrong with this approach now. The group that comes after /modules/ and with the change after /modules/kmp/ captures the kernel version. But the out-of-kernel KMPs do not have a kernel version. That's why prepending '/kmp' was seen as a 'solution' to make this code 'work' but it does not. The modules that are out of kernel should be versionless. |
In other words, the Large portions of the code rely on the fact that the directory structure is: with this, we will have to support another variant: The changes required to support both variants in weak-updates2 would be quite intrusive with a greater risk of breakages.
I'm not sure if people actually care.
NVIDIA's proprietary driver used a home-baked build/install method on SUSE and DKMS everywhere else. As they also provide a package with the open driver, they now us DKMS everywhere - including SUSE. What we are are trying to achieve with multiversioned packages is not wrong - and the SolidDriver people seem to like it. It is just very broken in some respects: that we can only publish a single module per kernel release and are thus bound to one release every four weeks is a major user experience problem. |
|
Why And supporting another variant is warranted, the modules that are installed out of kernel need to be handled differently. That is the group that captures kernel version should be tightened to reject anything that does not start with at least two place version such as |
Ok, it would make it easier to discover what scheme is used - the 'new' one under
Yes.
I'm not fully sure if I understand, but we should be stricter on the requirements of the module directory. The weak link in the kernel should probably be in a directory |
Out-of-kernel KMPs do have a kernel version. It's the version they are built
Why? |
This will install KMPs separately from the kernel they are built
for ('native kernel) using weak-updates for all kernel versions
- including the native one.
The weak-modules2 script already incorporates logic to create
weak updates for only one module version (i.e. the latest one)
per kernel version.
This way we can build multiple KMP versions against the same
kernel even with `multiversion(kernel)` set: the native kernel
will no longer see multiple driver modules installed leaving
it to 'depmod' to figure out which one to use.
Signed-off-by: Egbert Eich <eich@suse.com>
…15-sp7-alternative-module-path
Signed-off-by: Egbert Eich <eich@suse.com>
e4t
force-pushed
the
sles15-sp7-alternative-module-path
branch
from
ed01225 to
d8dd7df
Compare
That's backwards. The ABI is determined by imported symbol CRCs which are checked by depmod, and determines on which kernels the module can be installed (those that export those symbold with those CRCs). That might or might not be the kernel the module was built against. The version specifies the kernel from which the module cannot be removed because it's installed in its module directory. In this piece of obfuscated code There are two types of modules that wm2 recognizes:
It is not clear why /lib/modules is optional, possibly a bug. Now third type of module is needed |
|
Ok, now I understand what you mean. |
|
You are installing it outside of the kernel directory so you do need to solve that. Or add yet another special case which is no better, probably even worse. |
But you said we don't want to associate a module from a KMP with a kernel version any more, therefore, the kernel version would not appear in a module install path.
This still refers to above sed line from driver-check.sh?
Right. I've been wondering about this as well... |
|
Why is it moot? You can make the krel group optional, swap |
You don't check $krel and your $path test would be different. Just the test for $prefix makes sense unaltered. This is why I suggest to do an entirely separate loop for this case. |
I am not getting this argument. As @e4t wrote, of course they do. It's part of their package version. You're right that if we install the modules outside the tree of the kernel they were built for, we don't have to include the kernel version in the installation path. But if we don't, Thus if we want to continue using Or what am I overlooking here? |
|
As we're talking about weak-modules2, I would prefer a patch set that doesn't mandate any specific installation path. As far as wm2 is concerned, any path should be fine. The policy/convention where to install the modules, if we don't install them under |
|
Yes, exactly. The kernel version should be included in the path somewhere to avoid the conflict but that does not concern wm2. The only requirement is that the KMP is NOT installed someplace like /lib/modules/KVER where KVER looks like something that could potentially be a valid kernel version because in that case it's considered the old style KMP. |
|
So the idea is to support both 'old style' KMPs which install into |
|
I don't think that a new argument is required. wm2 should be able to work transparently with either KMP type. I am currently working on a patch set. The current status (yet untested) is in the PED-12049 branch. |
3 participants
This pull request contains:
/lib/modules/kmp. These changes may not be sufficient.multiversionsupport enabled.This requires testing as pieces may be missing. This set includes the changes in request #121.