From: Matthias Maennich <maennich@google.com>
To: Jessica Yu <jeyu@kernel.org>
Cc: Lucas De Marchi <lucas.de.marchi@gmail.com>,
linux-modules <linux-modules@vger.kernel.org>
Subject: Re: [PATCH] depmod: account for new namespace field in Module.symvers (for kernel versions >= 5.4)
Date: Wed, 4 Mar 2020 11:34:37 +0000 [thread overview]
Message-ID: <20200304113437.GB66900@google.com> (raw)
In-Reply-To: <20200304091833.GA14910@linux-8ccs>
On Wed, Mar 04, 2020 at 10:18:33AM +0100, Jessica Yu wrote:
>+++ Lucas De Marchi [03/03/20 22:28 -0800]:
>>On Fri, Feb 21, 2020 at 8:53 AM Jessica Yu <jeyu@kernel.org> wrote:
>>>
>>>depmod -e -E is broken for kernel versions >= 5.4, because a new
>>>namespace field was added to Module.symvers. Each line is tab delimited
>>>with 5 fields in total. E.g.,
>>>
>>> 0xb352177e\tfind_first_bit\tnamespace\tvmlinux\tEXPORT_SYMBOL
>>>
>>>When a symbol doesn't have a namespace, then the namespace field is empty:
>>>
>>> 0xb352177e\tfind_first_bit\t\tvmlinux\tEXPORT_SYMBOL
>>
>>Why is namespace added in the *middle*? We remember we specifically
>>talked about compatibility back when this was added. Why is it not at
>>the end so tools that don't know about namespace don't stop working?
>>
>>Lucas De Marchi
>
>Sigh, I do remember we had a short discussion upstream back in August
>[1] when we were tossing around Module.symvers format preferences. It
>is my fault for not having pushed the backwards compatibility option
>more instead of thinking it could be patched up in kmod tools. I think
>maybe the best course of option is to revert this upstream instead and
>Cc:stable.
>
>Sorry about this. :-/
Sorry, my fault. The discussion went first all around whether we should
append the namespace to the symbol name. This we did not do.
Then we discussed whether the last values of this line are actually
optional and we settled with the format now merged as nobody further
objected in the tail end of this discussion:
https://lore.kernel.org/linux-modules/20190828101640.GB25048@linux-8ccs/
We could probably move the namespace to the end as the other fields are
not optional (at least judging from write_dump() in modpost.c).
Cheers,
Matthias
>
>[1] https://lore.kernel.org/r/20190828094325.GA25048@linux-8ccs
>
next prev parent reply other threads:[~2020-03-04 11:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-21 16:52 [PATCH] depmod: account for new namespace field in Module.symvers (for kernel versions >= 5.4) Jessica Yu
2020-03-03 14:31 ` Jessica Yu
2020-03-04 6:28 ` Lucas De Marchi
2020-03-04 9:18 ` Jessica Yu
2020-03-04 11:34 ` Matthias Maennich [this message]
2020-03-06 0:10 ` Lucas De Marchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200304113437.GB66900@google.com \
--to=maennich@google.com \
--cc=jeyu@kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=lucas.de.marchi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).