Messages in this thread Patch in this message | | | From | Guo Ren <> | Date | Tue, 19 Sep 2023 08:56:24 +0800 | Subject | Re: [PATCH v1 1/2] LoongArch: Add missing headers |
| |
On Mon, Sep 18, 2023 at 4:23 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Mon, Sep 18, 2023 at 04:05:50PM +0800, Huacai Chen wrote: > > On Mon, Sep 18, 2023 at 2:49 PM Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > On Sat, Sep 16, 2023 at 08:05:52PM +0800, Huacai Chen wrote: > > > > On Sat, Sep 16, 2023 at 6:27 PM Andy Shevchenko > > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > On Fri, Sep 15, 2023 at 08:36:24AM +0800, Huacai Chen wrote: > > > > > > On Fri, Sep 15, 2023 at 2:53 AM Andy Shevchenko > > > > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > > On Thu, Sep 14, 2023 at 11:25:22PM +0800, Huacai Chen wrote: > > > > > > > > > > > > > Thank you for your patch, can this patch solve the problem below? > > > > > > > > https://lore.kernel.org/oe-kbuild-all/202309072237.9zxMv4MZ-lkp@intel.com/T/#u > > > > > > > > > > > > > > Nope, this just adds missing includes. > > > > > > > No functional change, so warnings will still be there. > > > > > > But I think a patch should solve a problem. > > > > > > > > > > No, that problem is static analyser concern, not the compiler nor linker. > > > > > > > > > > > If we don't get a build > > > > > > error or warning without this patch, does that mean the 'missing' > > > > > > headers are actually included indirectly? > > > > > > > > > > I might be missing something, but I do not see any build error in the above message. > > > > Hmm, then I think I will take the second patch only. > > > > > > Thanks, but can you shed a light why? > > > > > > The rule of thumb is to include the headers we are direct users of, we have not > > > to imply any other inclusions done by others, unless it's kinda same family of > > > headers (like types.h always includes compiler_types.h). Since in your case > > > the const.h is included the other two are missing and it's even worse, as I > > > understand you rely on the specific headers to be included _before_ using this > > > one in the users. > > I agree with you more or less, but I doubt there is another rule: no > > break, no fix. Please see: > > > > https://lore.kernel.org/loongarch/20221024070105.306280-1-chenhuacai@loongson.cn/T/#t > > > > Obviously static_key is used in page-flags.h and it really causes > > build errors once before, but at last I removed the inclusion of > > static_key.h to get that series merged. > > This is strange requirement to be honest. Doing like this is to move your > responsibility and understanding of the code to be a burden of the person who > volunteers cleaning up the header mess we have in the Linux kernel source tree. > > Since I'm the one who tries to fix some mess (in particular kernel.h), I am > pretty much know what I am talking about from the experience. > > Cc'ing Guo. Guo, can you shed a light on the rationale of your comment in > the above mentioned thread?
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h index 5c02720c53a5..9cdef3944a75 100644 --- a/include/linux/page-flags.h +++ b/include/linux/page-flags.h @@ -9,6 +9,7 @@ #include <linux/types.h> #include <linux/bug.h> #include <linux/mmdebug.h> +#include <linux/static_key.h> #ifndef __GENERATING_BOUNDS_H #include <linux/mm_types.h> #include <generated/bounds.h> My meaning is riscv needn't include the above header file to support HVO, and I just tested the above modification with riscv, all passed, so go ahead.
> > -- > With Best Regards, > Andy Shevchenko > >
-- Best Regards Guo Ren
| |