linux-kernel - Re: [git pull] drm for 6.15-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK7LNAT4NhxH8Dcg3PK=9Y0rGCmdgDj4K1MdSDZMCDswYNQ57A@mail.gmail.com>
Date: Wed, 2 Apr 2025 04:36:00 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, 
	Jani Nikula <jani.nikula@...ux.intel.com>, Dave Airlie <airlied@...il.com>, 
	dri-devel <dri-devel@...ts.freedesktop.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm for 6.15-rc1

On Wed, Apr 2, 2025 at 4:15 AM Jason Gunthorpe <jgg@...dia.com> wrote:
>
> On Wed, Apr 02, 2025 at 03:46:34AM +0900, Masahiro Yamada wrote:
> > However, it is annoying to make every header self-contained
> > "just because we are checking this".
>
> From my POV itis not "just because we are checking this", I have a
> very deliberate reason for wanting headers to be self contained:
>
> I want the clangd code indexer and editor integration to work fully.
>
> When clangd is asked by the editor for a report on a header file it
> cannot know the missing implicit includes and it's functionality is
> degraded. It reports fake compilation errors, can't do all the
> indexing functions, and is generally a bad experience. To be clear the
> header is parsed and loaded into the database when some C file
> included it, just the actual editing of the header doesn't work well.
>
> This is a very big day-to-day negative for working on the code. I'm
> frequently annoyed by headers that are pointlessly not self
> contained. I'd really welcome someone doing a cleanup here.
>
> I agree it should not be a hard rule. I was reading the thread you
> linked to and I'm thinking the approach is not optimal.
>
> The only header files that should be checked are ones that are
> actually used as part of the build with the current kconfig. Christoph
> is right that there are endless cases where headers should never be
> parsed outside of specific kconfig settings.
>
> So, I'd suggest a better way to run this is first build the kernel,
> then mine the gcc -MD output (ie stored in the .XX.cmd files) to
> generate a list of headers that are actually part of the build, then
> only test those. That eliminates all the kconfig problems. Opt out any
> special headers that really have a good reason not to be stand alone.


Sounds much better.



-- 
Best Regards
Masahiro Yamada