Re: [boot-time] [RFC] analyze-initcall-debug.py - a tool to analyze the initcall debug output

[Francesco Valla <francesco@valla.it>]

Hi Geert,

On Thursday, 5 December 2024 at 15:58:09 Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Francesco,
> 
> On Thu, Dec 5, 2024 at 3:47 PM Francesco Valla <francesco@valla.it> wrote:
> > On Tuesday, 3 December 2024 at 21:33:06 Bird, Tim <Tim.Bird@sony.com> wrote:
> > > > From: Francesco Valla <francesco@valla.it>
> > > > Top 10 init/probes durations:
> > > >  * 30200000.dss -> 523002us
> > >
> > > This call, and a lot of the others are missing function names.  Did you compile the kernel with
> > > CONFIG_KALLSYMS=y?
> > >
> > > If that's the case, is there a way to use the System.map file for the kernel (used on
> > > the machine where the dmesg was obtained from) to map these addresses
> > > to their respective  function names?
> >
> > These are not in fact addresses, but rather device names. In my understanding, they are printed
> > when a probe happens outside of the initialization function for their driver. I still don't have an idea
> > on how to match probes with their original initcall, in order to present the user the complete picture.
> 
> 30200000.dss corresponds to dss@30200000 in the DTS.
> 

This is a simple example, but what about e.g. an I2C device (say 2-004c)? Some heuristic
would be needed to search for the correct I2C bus and then the 0x4c device; once found,
the compatible would then need to be searched through the entire kernel sources / git repo
to match it to the correct driver.

At that point, the tool would probably be too complex to be maintainable, while the added
value very little IMO (in my experience, boot time optimization is done by experienced
developers, which can match a probe with its driver quite easily, even if manually).


Thank you!


Regards,

Francesco