+++ Masahiro Yamada [14/03/20 11:11 +0900]:
On Thu, Mar 12, 2020 at 2:02 AM Jessica Yu <jeyu@xxxxxxxxxx> wrote:
In order to preserve backwards compatability with kmod tools, we have to
move the namespace field in Module.symvers last, as the depmod -e -E
option looks at the first three fields in Module.symvers to check symbol
versions (and it's expected they stay in the original order of crc,
symbol, module).
In addition, update an ancient comment above read_dump() in modpost that
suggested that the export type field in Module.symvers was optional. I
suspect that there were historical reasons behind that comment that are
no longer accurate. We have been unconditionally printing the export
type since 2.6.18 (commit bd5cbcedf44), which is over a decade ago now.
Fix up read_dump() to treat each field as non-optional. I suspect the
original read_dump() code treated the export field as optional in order
to support pre <= 2.6.18 Module.symvers (which did not have the export
type field). Note that although symbol namespaces are optional, the
field will not be omitted from Module.symvers if a symbol does not have
a namespace. In this case, the field will simply be empty and the next
delimiter or end of line will follow.
Cc: stable@xxxxxxxxxxxxxxx
Fixes: cb9b55d21fe0 ("modpost: add support for symbol namespaces")
Tested-by: Matthias Maennich <maennich@xxxxxxxxxx>
Reviewed-by: Matthias Maennich <maennich@xxxxxxxxxx>
Reviewed-by: Lucas De Marchi <lucas.demarchi@xxxxxxxxx>
Signed-off-by: Jessica Yu <jeyu@xxxxxxxxxx>
While I am not opposed to this fix,
I did not even notice Module.symvers was official interface.
Kbuild invokes scripts/depmod.sh to finalize
the 'make modules_install', but I do not see the -E
option being used there.
I do not see Module.symvers installed in
/lib/modules/$(uname -r)/.
While that's true, distros typically package Module.symvers in their
linux-headers/kernel-devel (or equivalent) packages to support
external module builds. The -E option is usually used to do symbol
versioning/kabi checks with the Module.symvers file. Considering the
options, I think it will cause the least headaches down the line to
make this fix upstream and maintain backwards compatibility with kmod
rather than to patch kmod and remind distros to repackage because old
depmod versions don't work with the new Module.symvers anymore..
Thank you!
Jessica