On Mon, 5 Dec 2022 at 11:00, Arnd Bergmann <a...@arndb.de> wrote: > > On Sat, Dec 3, 2022, at 23:59, Bjørn Mork wrote: > > "Arnd Bergmann" <a...@arndb.de> writes: > >> On Sat, Dec 3, 2022, at 18:02, Bjørn Mork wrote: > >> > >>> Yes, I realize that ALL_KMODS only changes a small subset of symbols > >>> related to kmod packages. And I'm pretty sure HSR isn't part of that > >>> set. But I don't think that changes anything. This is a bug waiting to > >>> happen again. > >> > >> Do you have any alternative suggestions? Changing the dependency logic > >> would just cause runtime failures, and turning the dependencies all > >> into 'bool' symbols would cause a significant increase in kernel size > >> for distro builds that usually rely on things being in loadable modules. > > > > I was referring to the ALL_KMODS feature in OpenWrt, not to the > > PTP_1588_CLOCK_OPTIONAL symbol. As noted, there are many similar > > constructs in the kernel. Personally I think > > PTP_1588_CLOCK || PTP_1588_CLOCK=n would have been better, but I > > see your point and am definitely not going to argue about that ;-) > > > > Should have made it clearer that I believe the bug is in OpenWrt, not in > > the kernel. Just didn't notice that you were CC'ed into the discussion. > > Thought we were having an OpenWrt conversation... Sorry about the > > confusion. > > Ok, got it. Indeed this is a general problem for anyone wanting > to enable all kernel modules. I don't know how ALL_KMODS works > in OpenWRT, but there are other related problems that make this > a hard problem, which means you need a whitelist or blacklist > of some sort anyway: > > - Some modules are only visible depending on some other 'bool' > symbol, so you have to know which of those symbols to turn > on first > > - Some 'tristate' symbols not only control whether a module > is built but also impact the rest of the kernel. > > - Some modules are related to 'choice' statement or other > options that have mutually incompatible settings.
Luckily we already have solutions or workarounds in place for most of these, like encoding a hash of the kernel configuration in the version of the kernel (module) packages, and requiring an exact match on installation. Coming back to the original issue, I think there are only two viable (short-term) solutions for mvebu (and any other target affected): a) Set PTP_1588_CLOCK=y for mvebu, forcing it always on. b) Disallow PTP_1588_CLOCK for mvebu, preventing it from being enabled. so essentially treating it like a bool. Since most mvebu devices are on the beefier side with plenty of RAM and flash, I think a) is fine and shouldn't hurt too much. In theory it would also be possible to make the switch driver a module and let preinit load it (and include the ptp module optionally), but this would be effectively the same as a) for releases/ALL_KMOD builds, just more complicated, and less space efficient. Jonas _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
