[19.07] how to update kmod + userspace tools? (aka ksmbd)

[Andy2244]

I would like to discuss how i can safely update ksmbd for the released stable branch. My last attempt simply updating resulted in broken/mismatched kmod and userspace tools. The main problem is that the kmod won't be upgraded alongside the userspace tools. I'm not really sure why we can't upgrade existing kmod's, so need some insights here.

So even if we wait and only update on a minor version bump, than the new incompatible tools will be visible to older versions and if installed might break the setup? Is there a way to hide the userspace tools for specific versions. So as example if we merge the current version for 19.07.4, but need to hide them from all older versions?

The alternative is just to wait until 19.08/20.x is build/merged from master and never update "stable" older versions?

The other problem is that even if the kmod/userspace api's stabilize how would we do a security patch for the kmod on stable?

[neheb]

ping @jow-

[luizluca]

The way to provide compatible kmods updates for stable releases kernels is to build them with each stable SDK instead of only building with SDK from stage1. However, we would still need some place to publish them as kmods are target specific and, until now, target subdirs are frozen after release.

Any updates that break kernel API with userland packages might introduce more complexity than opkg dependency resolution can handle (matching "kernel" x "kmod" x "userland code" versions). But I'm not an expert on that matter. I think that this kind of change might only happen on unstable branch, not on stable ones.

[Andy2244]

Ideally i would like to send the stable #PR right before a minor release or to some special branch where such updates can be gathered, so at least any new FW install/upgrade will get the updates.
Yet i still need a way to hide the new userland tools from older releases, so they don't get installed via the package upgrade option.

This would be the easiest compromise i think, so updates will made it eventually to users if they do a FW upgrade.

[luizluca]

Yet i still need a way to hide the new userland tools from older releases, so they don't get installed via the package upgrade option.

I'm considering it is acceptable updates that break kernel x userland interface.

userland code could go into target specific repo (i.e.: https://downloads.openwrt.org/releases/19.07.3/targets/ath79/generic/packages/). But it will multiply an arch shareable package by the number of targets. We could also have a "version specific arch repo" converting https://downloads.openwrt.org/releases/19.07.3/packages/ into a real repo (and not a link) for packages that are dot-version specific. https://downloads.openwrt.org/releases/packages-19.07/mipsel_24kc/ would have to be referenced somehow using a different URI.

[brada4]

You can have kmod version range dependency if you do not trust Linux kernel ABI stability https://www.kernel.org/doc/Documentation/ABI/README

[neheb]

Alternatively, you could update only the userspace utils, up to a compatible version.

Updating kmods like this requires that users install new point releases of OpenWrt AFAIK.

[Andy2244]

Updating kmods like this requires that users install new point releases of OpenWrt AFAIK.

This would be fine, but if i send the PR won't existing users also see the updated userspace package?

Alternatively, you could update only the userspace utils, up to a compatible version.

Dosn't work, since the kmod jump is already to big. In future stable 19.x or 20.x the packages should be fine, since most stuff works now stable and i would only update for security fixes, which has the same problem.
Yet the current 19.x version is kinda outdated.

[Neustradamus]

This ticket has progressed no?

[luizluca]

This ticket has progressed no?

I don't think so. It might need a repo structure and build process redesign.

Current bot rebuild packages using the latest SDK. For kmods, it does not make sense to use the latest SDK that uses a still not-release kernel version but a released SDK or even every single dot-version previously released.

kmod are target specific and kernel version specific. And there is currently no place to publish that update. There are repos that are both target and dot-version specific, but they is no process that update them. And we have the general version arch (not target) specific repo where all packages updates goes but cannot deal with target specific packages.

opkg depedency solver is very limited and it might not be enough to select a target specific kmod with an older version that matched the current kernel installed.

Maybe github issues is not the place to discuss this problem as it will touch "openwrt core".