On Thu 2021-03-25 16:21:46, Stephen Boyd wrote: > Quoting peter enderborg (2021-03-25 04:06:17) > > On 3/24/21 9:55 AM, Christoph Hellwig wrote: > > > On Tue, Mar 23, 2021 at 07:04:31PM -0700, Stephen Boyd wrote: > > >> x5 : 0000000000000000 x4 : 0000000000000001 > > >> x3 : 0000000000000008 x2 : ffffff93fef25a70 > > >> x1 : ffffff93fef15788 x0 : ffffffe3622352e0 > > >> Call trace: > > >> lkdtm_WARNING+0x28/0x30 [lkdtm ed5019fdf5e53be37cb1ba7899292d7e143b259e] > > >> direct_entry+0x16c/0x1b4 [lkdtm ed5019fdf5e53be37cb1ba7899292d7e143b259e] > > > Yikes. No, please do not make the backtraces a complete mess for > > > something that serves absolutely no need. > > It serves a need. Please look at the patches to understand that I'm > adding the buildid to automatically find the associated debug > information on distros. > > > > > Would a "verbose" flag be acceptable solution? Something like write 1 to /sys/kernel/debug/verbose_stack to get the extra info. > > > > I think I see a need for it. > > > > Or a kernel config option and a commandline parameter? That would be OK > for me as I said on v1 of this series. I'll add that in for the next > patch series given all the distaste for some more hex characters next to > the module name. IMHO, a build configure option would fit the best here. It does not make sense to show the ID when the kernel vendor does not have a service to download the related binaries. But it makes sense to show the buildid by default when the provider/distro has the service and want to use the ID when handling bug reports. We could always add boot/run time options when people really need it. Best Regards, Petr
