On Thu, 12 Jan 2023 14:40:59 -0700
Lucas De Marchi <lucas.demarchi@xxxxxxxxx> wrote:
> On Wed, Jan 11, 2023 at 04:11:51PM +0000, Gary Guo wrote:
> >
> > struct modversion_info {
> >- unsigned long crc;
> >- char name[MODULE_NAME_LEN];
> >+ /* Offset of the next modversion entry in relation to this one. */
> >+ u32 next;
> >+ u32 crc;
> >+ char name[0];
>
> although not really exported as uapi, this will break userspace as this is
> used in the elf file generated for the modules. I think
> this change must be made in a backward compatible way and kmod updated
> to deal with the variable name length:
>
> kmod $ git grep "\[64"
> libkmod/libkmod-elf.c: char name[64 - sizeof(uint32_t)];
> libkmod/libkmod-elf.c: char name[64 - sizeof(uint64_t)];
>
> in kmod we have both 32 and 64 because a 64-bit kmod can read both 32
> and 64 bit module, and vice versa.
>
Hi Lucas,
Thanks for the information.
The change can't be "truly" backward compatible, in a sense that
regardless of the new format we choose, kmod would not be able to decode
symbols longer than "64 - sizeof(long)" bytes. So the list it retrieves
is going to be incomplete, isn't it?
What kind of backward compatibility should be expected? It could be:
* short symbols can still be found by old versions of kmod, but not
long symbols;
* or, no symbols are found by old versions of kmod, but it does not
fail;
* or, old versions of kmod would fail gracefully for not able to
recognise the format of __versions section, but it didn't do anything
crazy (e.g. decode it as old format).
Also, do you think the current modversion format should stick forever
or would we be able to migrate away from it eventually and fail old
versions of modprobe given enough time?
Best,
Gary
