Hi Robin, > -----Original Message----- > From: Robin Murphy <robin.murphy@xxxxxxx> > Sent: Thursday, June 1, 2023 9:34 AM > To: Besar Wicaksono <bwicaksono@xxxxxxxxxx>; suzuki.poulose@xxxxxxx; > catalin.marinas@xxxxxxx; will@xxxxxxxxxx; mark.rutland@xxxxxxx > Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux- > tegra@xxxxxxxxxxxxxxx; Thierry Reding <treding@xxxxxxxxxx>; Jonathan > Hunter <jonathanh@xxxxxxxxxx>; Vikram Sethi <vsethi@xxxxxxxxxx>; Richard > Wiley <rwiley@xxxxxxxxxx>; Eric Funsten <efunsten@xxxxxxxxxx> > Subject: Re: [PATCH v3] perf: arm_cspmu: Separate Arm and vendor module > > External email: Use caution opening links or attachments > > > On 2023-05-08 18:04, Besar Wicaksono wrote: > [...] > >>> +obj-$(CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU) += > >> arm_cspmu_impl.o > >> > >> Not sure what's up with this... I have no complaint with keeping the > >> impl infrastucture together in its own source file, but it still wants > >> to end up as part of arm_cspmu_module. Doing otherwise just adds > >> unnecessary overhead at many levels and invites more problems. > > > > My intention is to separate arm_cspmu_impl, arm_cspmu, and > > vendor backend into different modules. Here is the dependency I have in > mind: > > > > arm_cspmu_impl > > ____|____ > > | | > > arm_cspmu nvidia_cspmu > > > > This helps during device probe that the call to request_module can be made > > as a blocking call and the backend init_impl_ops will always be ready to use > after > > request_module returns. The code seems simpler this way. Could you please > > elaborate the potential issue that might arise with this approach? > > I see the intent; the main issue is that the implementation of it is > needlessly fiddly: arm_cspmu_impl is not useful on its own, and probably > only represents a few hundred bytes of code, so putting in a distinct > .ko which needs to be loaded separately is a relatively massive waste of > filesystem space and memory for what it is. Also if anything that > dependency is the wrong way round anyway - arm_cspmu could provide > generic PMU functionality just fine regardless of arm_cspmu_impl, but > arm_cspmu_impl definitely has a logical and functional dependency on > arm_cspmu in order to serve any user-visible purpose. > Thank you for the explanation. I will move the impl code back to arm_cspmu source file. With that, we no longer can load the backend module synchronously, so I will use the deferred probe approach as you suggested before. Thanks, Besar
