On Tue, Nov 05, 2024 at 04:26:51PM -0800, Matthew Maurer wrote: > On Fri, Nov 1, 2024 at 2:10 PM Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote: > > > > On Thu, Oct 31, 2024 at 01:00:28PM -0700, Matthew Maurer wrote: > > > > The question is, if only extended moversions are used, what new tooling > > > > requirements are there? Can you test using only extended modversions? > > > > > > > > Luis > > > > > > I'm not sure precisely what you're asking for. Do you want: > > > 1. A kconfig that suppresses the emission of today's MODVERSIONS > > > format? > > > > Yes that's right, a brave new world, and with the warning of that. > > OK, I can send another revision with a suppression config, perhaps > CONFIG_NO_BASIC_MODVERSIONS Great. > > > This would be fairly easy to do, but I was leaving it enabled > > > for compatibility's sake, at least until extended modversions become > > > more common. This way existing `kmod` tools and kernels would continue > > > to be able to load new-style modules. > > > > Sure, understood why we'd have both. > > > > > 2. libkmod support for parsing the new format? I can do that fairly > > > easily too, but wanted the format actually decided on and accepted > > > before I started modifying things that read modversions. > > > > This is implied, what I'd like is for an A vs B comparison to be able to > > be done on even without rust modules, so that we can see if really > > libkmod changes are all that's needed. Does boot fail without a new > > libkmod for this? If so the Kconfig should specificy that for this new > > brave new world. > > libkmod changes are not needed for boot - the userspace tools do not > examine this data for anything inline with boot at the moment, libkmod > only looks at it for kmod_module_get_versions, and modprobe only looks > at that with --show-modversions or --dump-modversions, which are not > normally part of boot. > > With the code as is, the only change will be that if a module with > EXTENDED_MODVERSIONS set contains an over-length symbol (which > wouldn't have been possible before), the overlong symbol's modversion > data will not appear in --show-modversions. After patching `libkmod` > in a follow-up patch, long symbols would appear as well. If booted > against an old kernel, long symbols will not have their CRCs in the > list to be checked. However, the old kernel could not export these > symbols, so it will fail to resolve the symbol and fail the load > regardless. Thanks for checking all this. It is exactly what I was looking for. All this should be part of the cover letter and Kconfig documentation. > If we add and enable NO_BASIC_MODVERSIONS like you suggested above, > today's --show-modversions will claim there is no modversions data. > Applying a libkmod patch will result in modversions info being > displayed by that command again. If booted against a new kernel, > everything will be fine. *This* is is the sort of information I was also looking for and I think it would be good to make it clear for the upcoming NO_BASIC_MODVERSIONS. > If booted against an old kernel, it will > behave as though there is no modversions information. Huh? This I don't get. If you have the new libkmod and boot an old kernel, that should just not break becauase well, long symbols were not ever supported properly anyway, so no regression. I'm not quite sure I understood your last comment here though, can you clarify what you meant? Anyway, so now that this is all cleared up, the next question I have is, let's compare a NO_BASIC_MODVERSIONS world now, given that the userspace requirements aren't large at all, what actual benefits does using this new extended mod versions have? Why wouldn't a distro end up preferring this for say a future release for all modules? Luis
