On Fri, Aug 21, 2020 at 8:18 PM David Laight <David.Laight@xxxxxxxxxx> wrote: > > From: Nicolas Boichat > > Sent: 21 August 2020 13:07 > ... > > > You might also want a #define that can set temporarily > > > to enable traces in a specific file/module even though > > > CONFIG_TRACE=n. > > > > I don't understand how traces are supposed to work with CONFIG_TRACE=n? > > Probably because I meant something different :-) > > You want the kernel built so that there are no (expanded) > calls to trace_printf() but with support for modules that > contain them. > > Then I can load a module into a distro kernel that > contains trace_printf() calls for debug testing. Gotcha. I think it already works this way ,-) So if you have CONFIG_TRACE=y, but no trace_printk in your vmlinux/kernel, no memory is used, and no warning splat (https://elixir.bootlin.com/linux/v5.8/source/kernel/trace/trace.c#L3160) is displayed. But then when you load a module with trace_printk, the buffers are allocated and the warning splat is printed. The magic is here: https://elixir.bootlin.com/linux/v5.8/source/kernel/trace/trace_printk.c#L53 My option wouldn't really change that. I mean, if you have CONFIG_TRACING_ALLOW_PRINTK=n when you compile your module, it'd fail at build time, but if you set it to =y, your module could happily build and load (with the big warning splat), no matter how you built your kernel (I mean, you still need CONFIG_TRACE=y, but CONFIG_TRACING_ALLOW_PRINTK doesn't matter). > Which is why I was suggesting a config option that > only rand-config builds would ever set that would > cause the calls to generate compile-time errors. I think I already answered that one above. We'd want that config option enabled on Chrome OS and we're not a rand-config build (I mean, we're a very carefully selected random config ,-P). Thanks, > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales)
