Re: module_license tree refreshed against linux-next

[Nick Alcock <nick.alcock@oracle.com>]

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