Re: [PATCH] perf/core: move all of the pmu devices into their own location

Ian Rogers
2025-02-05T16:48:34Z

On Tue, Feb 4, 2025 at 9:41 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Tue, Feb 04, 2025 at 10:17:17AM -0800, Ian Rogers wrote:
> > On Mon, Feb 3, 2025 at 11:05 PM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Mon, Feb 03, 2025 at 11:44:13AM -0800, Ian Rogers wrote:
> > > > On Mon, Feb 3, 2025 at 11:25 AM Greg Kroah-Hartman
> > > > <gregkh@linuxfoundation.org> wrote:
> > [snip]
> > > > > Note, if you all don't like "pmu_bus" for the name, that's fine, please
> > > > > let me know and I can rename it to something else, but it should be
> > > > > something to get these objects out of the root sysfs directory.
> > > >
> > > > Excuse my ignorance, does the event_source bus already provide a
> > > > similar solution?
> > > > ```
> > > > $ ls /sys/bus/event_source/devices
> > > > breakpoint i915 msr uncore_arb uncore_cbox_3
> > > > uncore_cbox_7 uprobe
> > > > cpu intel_bts power uncore_cbox_0 uncore_cbox_4 uncore_clock
> > > > cstate_core intel_pt software uncore_cbox_1 uncore_cbox_5
> > > > uncore_imc_free_running_0
> > > > cstate_pkg kprobe tracepoint uncore_cbox_2 uncore_cbox_6
> > > > uncore_imc_free_running_1
> > > > $ ls /sys/devices
> > > > breakpoint intel_pt platform uncore_arb uncore_cbox_5
> > > > uprobe
> > > > cpu isa pnp0 uncore_cbox_0 uncore_cbox_6
> > > > virtual
> > > > cstate_core kprobe power uncore_cbox_1 uncore_cbox_7
> > > > cstate_pkg LNXSYSTM:00 software uncore_cbox_2 uncore_clock
> > > > i915 msr system uncore_cbox_3 uncore_imc_free_running_0
> > > > intel_bts pci0000:00 tracepoint uncore_cbox_4 uncore_imc_free_running_1
> > > > ```
> > >
> > > Those are the exact same device structures :)
> > >
> > > Look at /sys/bus/event_source/devices/ those are symlinks back to
> > > /sys/devices. In other words, that's the exact same structures, and
> > > the mess in /sys/devices/ with these event devices is what I am trying
> > > to clean up.
> >
> > Thanks! Again my ignorance, why do we need pmu_bus?
>
> You need some sort of "bus" to group all of your devices on. It could
> also be a class, your call. This is how the driver model in the kernel
> works.

Sure, I wasn't clear how this mapped out in sysfs.

> > Could the symlinks in event_source be the actual devices?
>
> That's not how the driver model works.

Ok, so I guess that's what's confusing me. Where will the new devices
be in sysfs? If it is /sys/bus/pmu_bus then why is
/sys/bus/event_source a different case? I guess I should read docs and
the source :-)

> > Perhaps for temporary compatibility some symlinks could be placed in
> > /sys/devices?
>
> No, /sys/devices/ is never guaranteed to have stable placement.
>
> And define "temporary" :)

I need to finish my time machine to resolve issues like this :-) An
unfortunate thing with the PMU acronym is that it is overloaded and
can mean Power Management Unit. Events and perf are other names used
in the code and they don't seem overloaded, but it isn't clear to me
we care about the name being overloaded. I'm afflicted by thinking of
Digital Rights Management every time I hear DRM.

Thanks,
Ian

> thanks,
>
> greg k-h