On Mon, Feb 26, 2024 at 04:11:05PM +0300, Serge Semin wrote: > On Mon, Feb 26, 2024 at 01:29:54PM +0100, Arnd Bergmann wrote: > > On Mon, Feb 26, 2024, at 13:20, Serge Semin wrote: > > > On Mon, Feb 26, 2024 at 01:04:33PM +0100, Arnd Bergmann wrote: > > >> On Mon, Feb 26, 2024, at 12:27, Serge Semin wrote: > > > > > I see your point now. Thanks for clarification. IMO it would be less > > > readable due to the ifdef-ery and the new config, and less > > > maintainable due to the conditional compilation, but would provide a > > > more performant solution since the compiler will be able to inline the > > > singly used static method. Basically you suggest to emulate the weak > > > implementation by an additional kernel config. > > > > I mean the kernel config that you already need here, since > > the strong version of the function is already optional. > > Why would I need it if after this patch is applied the > mips_cm_l2sync_phys_base() method will be converted to a global weak > implementation? > > > > > > Not sure whether it would be better than a well-known > > > weak-attribute-based pattern. Anyway let's wait for the > > > Thomas' opinion about your suggestion. If he thinks > > > it would be better I'll update the patches. > > > > Weak functions are not used all that much outside of a > > couple of parts of the kernel. There is a lot of them > > in drivers/pci/, a little bit in acpi and efi, and > > then a bit in arch/*/, though most of that is in mips. > > + a lot of them in kernel/*, some in mm/* .) > > > > > Ifdef checks in .c files are not great, but at least they > > are much more common than __weak functions and self-documenting. > > Ok. I don't have concretely strong opinion about what is better. Let's > wait for what Thomas thinks about this. I've taken your patches as we get rid of this alias thing. As long as there is no big push against __weak I'm ok with this case. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]
