Message ID | 20211007154407.29746-5-andriy.shevchenko@linux.intel.com (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers |
Received: from vger.kernel.org ([23.128.96.18]) by www.linuxtv.org with esmtp (Exim 4.92) (envelope-from <linux-media-owner@vger.kernel.org>) id 1mYVZA-009LwE-5W; Thu, 07 Oct 2021 15:44:16 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242442AbhJGPqF (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Thu, 7 Oct 2021 11:46:05 -0400 Received: from mga02.intel.com ([134.134.136.20]:27707 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242421AbhJGPqE (ORCPT <rfc822;linux-media@vger.kernel.org>); Thu, 7 Oct 2021 11:46:04 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10130"; a="213423814" X-IronPort-AV: E=Sophos;i="5.85,355,1624345200"; d="scan'208";a="213423814" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Oct 2021 08:44:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,355,1624345200"; d="scan'208";a="478610545" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga007.jf.intel.com with ESMTP; 07 Oct 2021 08:44:04 -0700 Received: by black.fi.intel.com (Postfix, from userid 1003) id 5D01F3DB; Thu, 7 Oct 2021 18:44:10 +0300 (EEST) From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> To: Brendan Higgins <brendanhiggins@google.com>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Peter Zijlstra <peterz@infradead.org>, Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com, linux-media@vger.kernel.org Cc: Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>, Waiman Long <longman@redhat.com>, Boqun Feng <boqun.feng@gmail.com>, Sakari Ailus <sakari.ailus@linux.intel.com>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Mauro Carvalho Chehab <mchehab@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>, jic23@kernel.org, linux@rasmusvillemoes.dk, Thorsten Leemhuis <regressions@leemhuis.info> Subject: [PATCH v4 4/7] list.h: Replace kernel.h with the necessary inclusions Date: Thu, 7 Oct 2021 18:44:04 +0300 Message-Id: <20211007154407.29746-5-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20211007154407.29746-1-andriy.shevchenko@linux.intel.com> References: <20211007154407.29746-1-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-LSpam-Score: -4.7 (----) X-LSpam-Report: No, score=-4.7 required=5.0 tests=BAYES_00=-1.9,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1,RCVD_IN_DNSWL_MED=-2.3 autolearn=ham autolearn_force=no |
Series |
kernel.h further split
|
|
Commit Message
Andy Shevchenko
Oct. 7, 2021, 3:44 p.m. UTC
When kernel.h is used in the headers it adds a lot into dependency hell,
especially when there are circular dependencies are involved.
Replace kernel.h inclusion with the list of what is really being used.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
include/linux/list.h | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
Comments
On Thu, 7 Oct 2021 18:44:04 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > When kernel.h is used in the headers it adds a lot into dependency hell, > especially when there are circular dependencies are involved. > > Replace kernel.h inclusion with the list of what is really being used. > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > --- > include/linux/list.h | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/include/linux/list.h b/include/linux/list.h > index f2af4b4aa4e9..5dc679b373da 100644 > --- a/include/linux/list.h > +++ b/include/linux/list.h > @@ -2,11 +2,13 @@ > #ifndef _LINUX_LIST_H > #define _LINUX_LIST_H > > +#include <linux/container_of.h> > +#include <linux/const.h> > #include <linux/types.h> > #include <linux/stddef.h> > #include <linux/poison.h> Is there a reason you didn't quite sort this into alphabetical order? > -#include <linux/const.h> > -#include <linux/kernel.h> > + > +#include <asm/barrier.h> > > /* > * Circular doubly linked list implementation.
On Thu, Oct 07, 2021 at 05:16:35PM +0100, Jonathan Cameron wrote: > On Thu, 7 Oct 2021 18:44:04 +0300 > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: ... > Is there a reason you didn't quite sort this into alphabetical order? Glad you asked! Yes. Greg and possibly others will come and tell me that I mustn't do two things in one change.
On Thu, Oct 07, 2021 at 07:21:18PM +0300, Andy Shevchenko wrote: > On Thu, Oct 07, 2021 at 05:16:35PM +0100, Jonathan Cameron wrote: > > On Thu, 7 Oct 2021 18:44:04 +0300 > > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > ... > > > Is there a reason you didn't quite sort this into alphabetical order? > > Glad you asked! Yes. Greg and possibly others will come and tell me that > I mustn't do two things in one change. Actually I have to avoid moving const.h. I will change this in v5.
On Thu, Oct 07, 2021 at 05:16:35PM +0100, Jonathan Cameron wrote: > On Thu, 7 Oct 2021 18:44:04 +0300 Andy Shevchenko wrote: > > > When kernel.h is used in the headers it adds a lot into dependency hell, > > especially when there are circular dependencies are involved. > > > > Replace kernel.h inclusion with the list of what is really being used. > > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > --- > > include/linux/list.h | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/include/linux/list.h b/include/linux/list.h > > index f2af4b4aa4e9..5dc679b373da 100644 > > --- a/include/linux/list.h > > +++ b/include/linux/list.h > > @@ -2,11 +2,13 @@ > > #ifndef _LINUX_LIST_H > > #define _LINUX_LIST_H > > > > +#include <linux/container_of.h> > > +#include <linux/const.h> > > #include <linux/types.h> > > #include <linux/stddef.h> > > #include <linux/poison.h> > > Is there a reason you didn't quite sort this into alphabetical order? On a side note, if someone with perle knowledge could add a checkpatch warning for this, I think it would be very nice. I'm a bit tired of asking for alphabetical order in reviews :-) > > -#include <linux/const.h> > > -#include <linux/kernel.h> > > + > > +#include <asm/barrier.h> > > > > /* > > * Circular doubly linked list implementation.
On Thu, 2021-10-07 at 20:29 +0300, Laurent Pinchart wrote: > On Thu, Oct 07, 2021 at 05:16:35PM +0100, Jonathan Cameron wrote: > > On Thu, 7 Oct 2021 18:44:04 +0300 Andy Shevchenko wrote: > > > When kernel.h is used in the headers it adds a lot into dependency hell, > > > especially when there are circular dependencies are involved. > > > > > > Replace kernel.h inclusion with the list of what is really being used. [] > > > diff --git a/include/linux/list.h b/include/linux/list.h [] > > > @@ -2,11 +2,13 @@ > > > #ifndef _LINUX_LIST_H > > > #define _LINUX_LIST_H > > > > > > +#include <linux/container_of.h> > > > +#include <linux/const.h> > > > #include <linux/types.h> > > > #include <linux/stddef.h> > > > #include <linux/poison.h> > > > > Is there a reason you didn't quite sort this into alphabetical order? > > On a side note, if someone with perle knowledge could add a checkpatch > warning for this, I think it would be very nice. I'm a bit tired of > asking for alphabetical order in reviews :-) As are people that want reverse christmas tree. Neither of which I will do as I think both are poor form at best. If you want, this was a checkpatch reverse christmas tree attempt, as that was more common to some. https://lore.kernel.org/lkml/1478242438.1924.31.camel@perches.com/
On Fri, Oct 08, 2021 at 05:59:18PM -0700, Joe Perches wrote: > On Thu, 2021-10-07 at 20:29 +0300, Laurent Pinchart wrote: > > On Thu, Oct 07, 2021 at 05:16:35PM +0100, Jonathan Cameron wrote: > > > On Thu, 7 Oct 2021 18:44:04 +0300 Andy Shevchenko wrote: > > > > When kernel.h is used in the headers it adds a lot into dependency hell, > > > > especially when there are circular dependencies are involved. > > > > > > > > Replace kernel.h inclusion with the list of what is really being used. > [] > > > > diff --git a/include/linux/list.h b/include/linux/list.h > [] > > > > @@ -2,11 +2,13 @@ > > > > #ifndef _LINUX_LIST_H > > > > #define _LINUX_LIST_H > > > > > > > > +#include <linux/container_of.h> > > > > +#include <linux/const.h> > > > > #include <linux/types.h> > > > > #include <linux/stddef.h> > > > > #include <linux/poison.h> > > > > > > Is there a reason you didn't quite sort this into alphabetical order? > > > > On a side note, if someone with perle knowledge could add a checkpatch > > warning for this, I think it would be very nice. I'm a bit tired of > > asking for alphabetical order in reviews :-) > > As are people that want reverse christmas tree. > Neither of which I will do as I think both are poor form at best. Reverse xmas tree order is just a matter of style, while alphabetical ordering of headers helps catching duplicate, including when merging branches that both add the same header in different locations. I thus think there's a technical value to it. > If you want, this was a checkpatch reverse christmas tree attempt, > as that was more common to some. > > https://lore.kernel.org/lkml/1478242438.1924.31.camel@perches.com/
diff --git a/include/linux/list.h b/include/linux/list.h index f2af4b4aa4e9..5dc679b373da 100644 --- a/include/linux/list.h +++ b/include/linux/list.h @@ -2,11 +2,13 @@ #ifndef _LINUX_LIST_H #define _LINUX_LIST_H +#include <linux/container_of.h> +#include <linux/const.h> #include <linux/types.h> #include <linux/stddef.h> #include <linux/poison.h> -#include <linux/const.h> -#include <linux/kernel.h> + +#include <asm/barrier.h> /* * Circular doubly linked list implementation.