On 24/06/2019 23.53, Nick Desaulniers wrote: > On Thu, Jun 20, 2019 at 1:46 PM Rasmus Villemoes > <li...@rasmusvillemoes.dk> wrote: >> >> I've pushed them to https://github.com/Villemoes/linux/tree/dyndebug_v6 >> . They rebase pretty cleanly to just about anything you might prefer >> testing on. Enabling it for arm64 or ppc64 is a trivial two-liner >> similar to the x86 patch (and similar to the previous patches for those >> arches). Thanks for volunteering to test this :) > > Compile tested x86_64 allyesconfig > boot tested x86_64 defconfig+CONFIG_DYNAMIC_DEBUG > > (just curious why the Kconfig changes for arm64 or ppc64 aren't > included in this set?)
Partly because I can't boot test those and this has proven much more delicate than I thought, partly because none of the maintainers for those arches have weighed in. So I'd rather have the bare minimal land, then send specific individual patches for arm64 and ppc64. >>> Anything I should test at runtime besides a boot >>> test? >> >> Well, apart from booting, I've mostly just tested that the debugfs >> control file is identical before and after enabling relative pointers, > > mainline x86_64 defconfig+CONFIG_DYNAMIC_DEBUG > $ cat /dfs/dynamic_debug/control | wc -l > 2488 > > > mainline x86_64 defconfig+CONFIG_DYNAMIC_DEBUG+this patch series > $ cat /dfs/dynamic_debug/control | wc -l > 2486 > > (seems like maybe 2 are missing? Let me try to collect a diff. Maybe > 2 were removed in this series?) Hm, no pr_debugs should have been added or removed. Perhaps you have a slightly different set of modules loaded? Otherwise there's something odd going on, and a diff would be really nice. It's possible that the order of the lines are different, so you may have to sort them to get a meaningful diff. (A diff is nice extra sanity check even if the line count matches, of course). >> and that enabling/disabling various pr_debug()s by writing to the >> control file takes effect. I should only be changing the format for > > Can you suggest one that's easy to test? The ones in lib/kobject.c are triggered fairly often I think. Thanks, Rasmus