Re: [PATCH 0/4] firewire: ohci: remove obsolete module-level debug parameter

Hi Adam,

On Tue, Oct 21, 2025 at 11:36:42PM -0700, Adam Goldman wrote:
> On Thu, Aug 21, 2025 at 09:30:13AM +0900, Takashi Sakamoto wrote:
> > The "firewire-ohci" module has long provided a "debug" parameter that
> > enabled debug logging by calling printk() from hardIRQ context.
> > 
> > Between v6.11 and v6.12, a series of tracepoints events have been added as
> > a more suitable alternative. Since v6.12, a commit cd7023729877
> > ("firewire: ohci: deprecate debug parameter") has already marked the
> > parameter as deprecated.
> > 
> > This series removes the parameter, as its functionality is now fully
> > covered by tracepoints.
> 
> Hi Takashi,
> 
> Now that the "debug" parameter has been removed, can you provide 
> instructions for using tracepoints? For example, what is the new 
> procedure instead of adding "debug=7" to the module command line? What 
> is the equivalent to 
> "echo -1 > /sys/module/firewire_ohci/parameters/debug"?
> 
> -- Adam

In my opinion, using tracepoints means to leave from the message buffer
for printk once. There are several ways to retrieve the content of ring
buffer for tracepoints events in userspace, and we have some userspace
applications to utilize them.

1. By debugfs
2. By file descriptor returned from perf_event_open(2) system call
3. By tracefs
4. By printk message buffer
5. By BPF

For the 1st option, it is required to mount 'debugfs' into anywhere in
your root file system. In my environment:

```
$ mount | grep debugfs
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
```

Then you can see many directories for events under
'/sys/kernel/debug/tracing/events/'. For the events specific to this
subsystem:

* /sys/kernel/debug/tracing/events/firewire_ohci
  * irq
  * self_id_complete
* /sys/kernel/debug/tracing/events/firewire
  * bus_reset_handle
  * self_id_sequence
  * bus_reset_schedule
  * bus_reset_postpone
  * bus_reset_initiate
  * async_phy_inbound
  * async_phy_outbound_initiate
  * async_phy_outbound_complete
  * etc...

Each of the above directory includes 'enable' file. By writing 1 to the
file, the corresponding event is enabled.

```
$ echo 1 > /sys/kernel/debug/tracing/events/firewire/self_id_sequence/enable
```

The read operation to '/sys/kernel/debug/tracing/trace' retrieves the event
content from the ring buffer.

```
$ cat /sys/kernel/debug/tracing/trace
 irq/121-firewir-73902   [000] ...1. 114132.060856: self_id_sequence: card_index=0 generation=4 phy_id=0x00 link_active=true gap_count=63 scode=3 contender=true power_class=4 initiated_reset=true port_status={0x1,0x1,0x1} self_id_sequence={0x807fcc56}
```

I think this is the most-straightforward way to use the tracepoints
framework. Using cat and shell-builtin echo commands satisfies our aim.


For the 2nd option, perf(1) command would be a good fontend application.
For tracepoints events, 'list', 'record', and 'script' subcommands are
available to enumerate events, record events, and report. In
detail, see https://perfwiki.github.io/main/.


For the 3rd option, trace-cmd(1) would be a good frontend application.
For tracepoints events, 'list', 'record', and 'report' subcommands are
available. In detail, see https://www.trace-cmd.org/.


For the 4th option, we need to use either some kernel command-line options
or corresponding sysctl configurations:
* tp_printk
* trace_event

This way has an advantage at boot time analysis. In detail, see:
* https://docs.kernel.org/admin-guide/kernel-parameters.html


I have never used the 5th option, since it is relatively new,


Regards

Takashi Sakamoto