All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Petr Mladek <pmladek@suse.com>, Ingo Molnar <mingo@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	John Ogness <john.ogness@linutronix.de>
Subject: Re: header circular dependencies
Date: Tue, 4 Jan 2022 16:52:25 +0200	[thread overview]
Message-ID: <CAHp75Vd0-__zV72YGpNqjdV6kOEQYcPkHeyEHPCQ0iL6K8oidQ@mail.gmail.com> (raw)
In-Reply-To: <YdRdhE9z+Yyxwrhj@alley>

On Tue, Jan 4, 2022 at 4:46 PM Petr Mladek <pmladek@suse.com> wrote:
>
> On Wed 2021-12-22 21:08:39, Andy Shevchenko wrote:
> > `make headerdep` is full of printk.h circular dependencies, like
> >
> > include/kvm/arm_vgic.h:18: warning: recursive header inclusion
> > In file included from linux/printk.h,
> >                 from linux/dynamic_debug.h:188
> >                 from linux/printk.h:555 <-- here
>
> This one looks like false positive:
>
>    + printk.h includes dynamic_debug.h when CONFIG_DYNAMIC_DEBUG_CORE
>    + dynamic_debug.h includes printk.h when !CONFIG_DYNAMIC_DEBUG_CORE
>
> But there seem to be other cycles, for example:
>
>    + printk.h
>      + dynamic_debug.h
>        + jump_label.h
>          + bug.h
>            + asm/bug.h
>              + printk.h
>
> I guess that it somehow works _only_ because printk.h includes
> dynamic_debug.h late. It probably defines everything that is needed
> by bug.h early enough.
>
> > I'm wondering if it's a false positive?
> > In either case, can we teach the headerdep not to complain by fixing
> > the culprit?
>
> I am scratching my head how to clean this up. All the dependencies
> make sense. The main problem is that all headers provide a lot of
> inlined functionality. The inlining is often important either because
> of speed or because every caller needs to have its own data structure
> (struct _ddebug, struct static_key).
>
> I can't find any good solution at the moment. But I am still slowed
> down after the holidays.

Thanks for looking into this.

Meanwhile (I haven't looked at that myself) Ingo announced some of his
long work on the topic:
https://lore.kernel.org/lkml/YdIfz+LMewetSaEB@gmail.com/

Perhaps he has a solution there.


-- 
With Best Regards,
Andy Shevchenko

  reply	other threads:[~2022-01-04 14:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-22 19:08 header circular dependencies Andy Shevchenko
2021-12-22 19:10 ` Andy Shevchenko
2022-01-04 14:45 ` Petr Mladek
2022-01-04 14:52   ` Andy Shevchenko [this message]
2022-01-05  8:46     ` Petr Mladek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHp75Vd0-__zV72YGpNqjdV6kOEQYcPkHeyEHPCQ0iL6K8oidQ@mail.gmail.com \
    --to=andy.shevchenko@gmail.com \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.