module_license tree refreshed against linux-next

module_license tree refreshed against linux-next

[Nick Alcock]

Just a note, now -rc3 is out and you might be considering looking at the
module-license stuff again: the current module_license tree at
https://github.com/nickalcock/linux module-license has been updated
against latest linux-next, upstreamed commits dropped, and all the
acked-bys/reviewed-bys I am aware of added. I've also introduced a few
more commits doing removals of MODULE_*, module.h inclusions etc where
maintainers have asked for it (but have not done that treewide).

I have not dropped commits with Greg K-H as maintainer simply because I
kept on oscillating on doing that, so I thought I'd leave the commits in
so you have the option to do either.

Test-built with make allyesconfig and allmodconfig (with clean tristate
checker runs) on x86-64: runs on aarch64 are underway. Not even tried
booting the result because booting an allyesconfig kernel is usually
troublesome even without linux-next in the mix :P

If you want a branch containing only those commits that have
acked-by/reviewed-by, I can do that, but it would have depressingly few
commits in (largely because most people who acked commits also took them
in, so I dropped them from my tree).

I hope my doing this makes your life a tiny bit easier!

Re: module_license tree refreshed against linux-next

[Luis Chamberlain]

On Tue, Mar 21, 2023 at 10:29:08AM +0000, Nick Alcock wrote:
> I have not dropped commits with Greg K-H as maintainer simply because I
> kept on oscillating on doing that, so I thought I'd leave the commits in
> so you have the option to do either.

No, I don't want to do that work, please drop Greg's drivers.

  Luis

Re: module_license tree refreshed against linux-next

[Nick Alcock]

On 21 Mar 2023, Luis Chamberlain verbalised:

> On Tue, Mar 21, 2023 at 10:29:08AM +0000, Nick Alcock wrote:
>> I have not dropped commits with Greg K-H as maintainer simply because I
>> kept on oscillating on doing that, so I thought I'd leave the commits in
>> so you have the option to do either.
>
> No, I don't want to do that work, please drop Greg's drivers.

OK! Repushed to the same branch, sans what I *think* is the relevant set:

binder: remove MODULE_LICENSE in non-modules
serial: remove MODULE_LICENSE in non-modules
vgacon: remove MODULE_LICENSE in non-modules
tty: serial: imx: remove MODULE_LICENSE in non-modules
tty: remove MODULE_LICENSE in non-modules

I hope that's right -- it's all the patches he was directly Cc:ed on.

(other branches containing kallmodsyms as a whole, etc, have not yet
been refreshed at all and are old: I'll get to it).

Re: module_license tree refreshed against linux-next

[Luis Chamberlain]

On Tue, Mar 21, 2023 at 04:52:20PM +0000, Nick Alcock wrote:
> On 21 Mar 2023, Luis Chamberlain verbalised:
> 
> > On Tue, Mar 21, 2023 at 10:29:08AM +0000, Nick Alcock wrote:
> >> I have not dropped commits with Greg K-H as maintainer simply because I
> >> kept on oscillating on doing that, so I thought I'd leave the commits in
> >> so you have the option to do either.
> >
> > No, I don't want to do that work, please drop Greg's drivers.
> 
> OK! Repushed to the same branch, sans what I *think* is the relevant set:
> 
> binder: remove MODULE_LICENSE in non-modules
> serial: remove MODULE_LICENSE in non-modules
> vgacon: remove MODULE_LICENSE in non-modules
> tty: serial: imx: remove MODULE_LICENSE in non-modules
> tty: remove MODULE_LICENSE in non-modules
> 
> I hope that's right -- it's all the patches he was directly Cc:ed on.
> 
> (other branches containing kallmodsyms as a whole, etc, have not yet
> been refreshed at all and are old: I'll get to it).

OK I merged this set onto modules-next. Thanks.

  Luis

Re: module_license tree refreshed against linux-next

[Nick Alcock]

[Cc:ed Steve because I think he wanted something like this]

On 22 Mar 2023, Luis Chamberlain spake thusly:

> On Tue, Mar 21, 2023 at 04:52:20PM +0000, Nick Alcock wrote:
>> On 21 Mar 2023, Luis Chamberlain verbalised:
>> 
>> > On Tue, Mar 21, 2023 at 10:29:08AM +0000, Nick Alcock wrote:
>> >> I have not dropped commits with Greg K-H as maintainer simply because I
>> >> kept on oscillating on doing that, so I thought I'd leave the commits in
>> >> so you have the option to do either.
>> >
>> > No, I don't want to do that work, please drop Greg's drivers.
>> 
>> OK! Repushed to the same branch, sans what I *think* is the relevant set:
>> 
>> binder: remove MODULE_LICENSE in non-modules
>> serial: remove MODULE_LICENSE in non-modules
>> vgacon: remove MODULE_LICENSE in non-modules
>> tty: serial: imx: remove MODULE_LICENSE in non-modules
>> tty: remove MODULE_LICENSE in non-modules
>> 
>> I hope that's right -- it's all the patches he was directly Cc:ed on.
>> 
>> (other branches containing kallmodsyms as a whole, etc, have not yet
>> been refreshed at all and are old: I'll get to it).
>
> OK I merged this set onto modules-next. Thanks.

Fabulous! It really is time for me to get back to making the kallmodsyms
commit logs and cover letters comprehensible to people who aren't me...


btw, as proof this is not all totally useless makework I just
implemented this (in something I can't even think of upstreaming until
after kallmodsyms since it relies on it):

% echo function > /sys/kernel/tracing/current_tracer
% echo 1 > /sys/kernel/tracing/options/sym-unambiguous
% cat /sys/kernel/tracing/trace
          <idle>-0       [001] d.h4.    65.103804: available_idle_cpu <-select_idle_sibling@fair.o
[...]
          <idle>-0       [005] d.h3.    99.316093: _raw_spin_unlock[bcache] <-scheduler_tick
          <idle>-0       [005] d.h2.    99.316093: perf_event_task_tick@events/core.o <-scheduler_tick
          <idle>-0       [005] d.h2.    99.316094: perf_adjust_freq_unthr_context@events/core.o <-perf_event_task_tick@events/core.o
          <idle>-0       [005] d.h2.    99.316094: __rcu_read_lock <-perf_event_task_tick@events/core.o
          <idle>-0       [005] d.h2.    99.316095: __rcu_read_unlock <-scheduler_tick
[...]
  kworker/u32:11-121     [010] ...1.    98.665295: _raw_spin_lock_irqsave[bcache] <-__wake_up_common_lock@build_utility.o
  kworker/u32:11-121     [010] d..2.    98.665295: __wake_up_common@build_utility.o <-__wake_up_common_lock@build_utility.o
[...]
  kworker/u32:11-121     [010] d..4.    98.665308: set_task_cpu <-try_to_wake_up
[...]

Object file name fragments and module names in tracer output --
including builtin module names, though it's not obvious from that
snippet. All names unambiguous, though I'm not sure about the notation:
using @ is neat but it's not really obvious to the user that this
corresponds to {...} in /proc/kallmodsyms, though hopefully it is
obvious what it means regardless.

(I am totally open to improved notations: I changed my mind three times
already.)

With the kallmodsyms stuff in place, and a bit more to allow kernel-side
access to it, doing this was not much code at all:

 kernel/trace/ftrace.c                 | 21 ++++++++++++++++++---
 kernel/trace/trace.c                  |  1 +
 kernel/trace/trace.h                  |  3 ++-
 kernel/trace/trace_output.c           | 21 ++++++++++++++++++---
 kernel/trace/trace_output.h           |  3 ++-
 kernel/trace/trace_recursion_record.c |  4 ++--
 6 files changed, 43 insertions(+), 10 deletions(-)

(and really you can drop the kernel/trace/ftrace.c part entirely, which
is just updating the stats output for the sheer hell of it).

(the tree is still under internal review and probably still awful, but
if you want to see it anyway I can push it somewhere external.)

Re: module_license tree refreshed against linux-next

[Luis Chamberlain]

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.

  Luis

Re: module_license tree refreshed against linux-next

[Steven Rostedt]

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. But I don't like the
option name.

Perhaps "sym-file" ?

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".

Thanks,

-- Steve

Re: module_license tree refreshed against linux-next

[Nick Alcock]

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)

Re: module_license tree refreshed against linux-next

[Steven Rostedt]

On Thu, 23 Mar 2023 20:38:02 +0000
Nick Alcock <nick.alcock@oracle.com> wrote:

> Oh the name is dreadful! Better name suggestions much appreciated.

And kernel developers are notorious at picking bad names.

> 
> > 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.

 sym-nodups ?

 sym-differentiate ?

I don't think sym-unique is worse than sym-unambigous

We could always put this question out to social media.

-- Steve