From: Nick Alcock <nick.alcock@oracle.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
linux-modules <linux-modules@vger.kernel.org>
Subject: Re: module_license tree refreshed against linux-next
Date: Thu, 23 Mar 2023 20:38:02 +0000 [thread overview]
Message-ID: <87v8irmcet.fsf@esperi.org.uk> (raw)
In-Reply-To: <20230323160022.2e4331e9@gandalf.local.home> (Steven Rostedt's message of "Thu, 23 Mar 2023 16:00:22 -0400")
On 23 Mar 2023, Steven Rostedt outgrape:
> On Thu, 23 Mar 2023 12:43:29 -0700
> Luis Chamberlain <mcgrof@kernel.org> wrote:
>
>> On Thu, Mar 23, 2023 at 04:45:02PM +0000, Nick Alcock wrote:
>> > [Cc:ed Steve because I think he wanted something like this]
>> >
>> > % echo 1 > /sys/kernel/tracing/options/sym-unambiguous
>>
>> I'd like to really hear if Steven is really super excited about this or not.
>> You keep saying he wants it, but I haven't him say it yet on the lists.
>
> I'm not "super excited" but I'm also not against it.
Yeah, honestly I don't expect anyone to be *super* excited by any of
this. It's not that big. It's not like, say, ftrace as a whole. It's
just something that can be used to implement small improvements here and
there.
> But I don't like the
> option name.
Oh the name is dreadful! Better name suggestions much appreciated.
> Perhaps "sym-file" ?
... Yes, except that it also decorates with built-in module names.
> Or does this happen only when there's more than one function? Either way,
> let's try to come up with something other than "sym-unambiguous".
It happens only when at least one symbol in a given (object file *
built-in module) pair would be ambiguous with respect to some other
symbol with the same name without being given at least one of those two.
It's a bit hard to pack into a couple of words... sym-unique is even
worse, sym-objname is deeply unclear (what's an objname?) sym-filenames
maybe? The question really is what property users care about, and I was
hoping it would be that with this option turned on you can always tell
all symbols apart from all other symbols.
--
NULL && (void)
next prev parent reply other threads:[~2023-03-23 20:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-21 10:29 module_license tree refreshed against linux-next Nick Alcock
2023-03-21 16:32 ` Luis Chamberlain
2023-03-21 16:52 ` Nick Alcock
2023-03-22 23:33 ` Luis Chamberlain
2023-03-23 16:45 ` Nick Alcock
2023-03-23 19:43 ` Luis Chamberlain
2023-03-23 20:00 ` Steven Rostedt
2023-03-23 20:38 ` Nick Alcock [this message]
2023-03-23 23:08 ` Steven Rostedt
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=87v8irmcet.fsf@esperi.org.uk \
--to=nick.alcock@oracle.com \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=rostedt@goodmis.org \
/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).