[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aSiWH1XPnlVZYLXz@smile.fi.intel.com>
Date: Thu, 27 Nov 2025 20:19:11 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Joe Perches <joe@...ches.com>
Cc: Randy Dunlap <rdunlap@...radead.org>,
"Dr. David Alan Gilbert" <linux@...blig.org>,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
workflows@...r.kernel.org, linux-remoteproc@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Danilo Krummrich <dakr@...nel.org>,
Jonathan Corbet <corbet@....net>,
Dwaipayan Ray <dwaipayanray1@...il.com>,
Lukas Bulwahn <lukas.bulwahn@...il.com>,
Bjorn Andersson <andersson@...nel.org>,
Mathieu Poirier <mathieu.poirier@...aro.org>
Subject: Re: [PATCH v2 1/1] docs: Update documentation to avoid mentioning of
kernel.h
On Thu, Nov 27, 2025 at 09:34:51AM -0800, Joe Perches wrote:
> On Wed, 2025-11-26 at 22:46 +0100, Andy Shevchenko wrote:
> > For several years, and still ongoing, the kernel.h is being split
> > to smaller and narrow headers to avoid "including everything" approach
> > which is bad in many ways.
>
> And I still think precompiled headers can be beneficial to
> standardize using kernel.h to reduce overall compilation time.
Same Q, why don't we have just a single header? Why do we have a concept of
(modular) headers to begin with? And Ingo's approach shows that the problem
can be solved properly by dividing headers to be more logical smaller pieces.
So, I have a strong disagreement for using kernel.h. At least not in this form,
It needs to be cleaned up and some sanity given to that train wreck. When it's
done, we can think of precompiled headers.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists