From: Jani Nikula <jani.nikula@linux.intel.com>
To: Masahiro Yamada <masahiroy@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jason Gunthorpe <jgg@nvidia.com>, Dave Airlie <airlied@gmail.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [git pull] drm for 6.15-rc1
Date: Tue, 01 Apr 2025 22:28:16 +0300 [thread overview]
Message-ID: <87a58z3cmn.fsf@intel.com> (raw)
In-Reply-To: <CAK7LNAQThGkgtKgquRPv8Ysi_omedRthF1_++apKda-xWeWcbA@mail.gmail.com>
On Wed, 02 Apr 2025, Masahiro Yamada <masahiroy@kernel.org> wrote:
> On Wed, Apr 2, 2025 at 1:12 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> On Tue, 1 Apr 2025 at 05:21, Jani Nikula <jani.nikula@linux.intel.com> wrote:
>> >
>> > The header checks have existed for uapi headers before, including the,
>> > uh, turds, but apparently adding them in drm broke the camel's back.
>>
>> The uapi header test things never caused any problems for me [*],
>> because they don't actually pollute the source tree.
>>
>> Why? Because they all end up in that generated 'usr/include/' directory.
>>
>> So when I look at the source files, filename completion is entirely
>> unaffected, and it all works fine.
>>
>> Look, I can complete something like
>>
>> include/uapi/asm-generic/poll.h
>>
>> perfectly fine, because there is *not* some generated turd that affects it all.
>>
>> Because for the uapi files those hdrtest files end up being in
>>
>> ./usr/include/asm-generic/poll.hdrtest
>>
>> and I never have any reason to really look at that subdirectory at
>> all, since it's all generated.
>>
>> Or put another way - if I _were_ to look at it, it would be exactly
>> because I want to see some generated file, in which case the 'hdrtest'
>> turd would be part of it.
>>
>> (Although I cannot recall that ever having actually happened, to be
>> honest - but looking at various header files is common, and I hit the
>> drm case immediately)
>>
>> Would you mind taking more of that uapi approach than creating that
>> hidden directory specific to the drm tree? Maybe this could *all* be
>> generalized?
>>
>> Linus
>>
>> [*] I say "never caused any problems for me", but maybe it did way in
>> the past and it was fixed and I just don't recall. I have definitely
>> complained about pathname completion issues to people before.
>
> I know you dislike this, and I NACKed this before (but too late):
> https://lore.kernel.org/dri-devel/CAK7LNATHXwEkjJHP7b-ZmhzLfyyuOdsyimna-=r-sJk+DxigrA@mail.gmail.com/
>
> Compile-testing UAPI headers is useful
> (and I believe this is the only case where it is useful)
> because userspace is independent of any CONFIG option,
> and we have no control over the include order in
> userspace programs.
>
> In contrast, kernel-space headers are conditionally parsed,
> depending on CONFIG options.
>
> You dislike this feature for the reason of TAB-completion,
> but I am negative about this feature from another perspective.
>
> We cannot avoid a false-positive:
> https://lore.kernel.org/all/20190718130835.GA28520@lst.de/
>
> It is not <drm/*.h> but <linux/*.h>
> However, it is annoying to make every header self-contained
> "just because we are checking this".
As I explained earlier in the thread, it's not *just* about the headers
being self-contained. It's *also* about checking header guards and
kernel-doc, maybe other things in the future.
If it's possible to do opt-in build checks for this, and catch all of
these pre-merge, why shouldn't we? We can catch a whole class of build
issues and bypass the subsequent fixes with this, and make life easier
for us.
> Actually, it is not a real problem when the relevant
> CONFIG option is disabled.
> I did not interrupt him because he was doing this
> checkunder drivers/gpu/drm/i915/.
> ()
> But, I am opposed to expanding it to more-global include/drm/,
> or any other subsystem.
>
> In my opinion, the right fix is
> "git revert 62ae45687e43"
>
>
> If we continue this, maybe leave a caution
> in capital letters?
Or maybe let the subsystem and driver maintainers decide?
I don't think there's a *single* header under include/drm where them
being self-contained depends on a config option. I'm sure there are
plenty in include/linux, but I wouldn't say they *all* do.
Maybe help and support us in generalizing this in scripts/Makefile.build
to avoid the boilerplate, and make Linus happy, instead of trying to
block us from having nice things? Please?
BR,
Jani.
>
>
> diff --git a/include/Kbuild b/include/Kbuild
> index 5e76a599e2dd..4dff23ae51a4 100644
> --- a/include/Kbuild
> +++ b/include/Kbuild
> @@ -1 +1,3 @@
> +# The drm subsystem is strict about the self-containedness of header files.
> +# OTHER SUBSYSTEMS SHOULD NOT FOLLOW THIS PRACTICE.
> obj-$(CONFIG_DRM_HEADER_TEST) += drm/
>
>
>
> --
> Best Regards
>
> Masahiro Yamada
--
Jani Nikula, Intel
next prev parent reply other threads:[~2025-04-01 19:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-28 2:53 [git pull] drm for 6.15-rc1 Dave Airlie
2025-03-29 0:47 ` Linus Torvalds
2025-03-31 10:17 ` Jani Nikula
2025-03-31 11:03 ` Simona Vetter
2025-03-31 13:31 ` Jason Gunthorpe
2025-04-01 12:21 ` Jani Nikula
2025-04-01 16:12 ` Linus Torvalds
2025-04-01 18:46 ` Masahiro Yamada
2025-04-01 19:14 ` Jason Gunthorpe
2025-04-01 19:36 ` Masahiro Yamada
2025-04-01 19:42 ` Jani Nikula
2025-04-01 19:46 ` Jason Gunthorpe
2025-04-02 12:56 ` Jani Nikula
2025-04-02 13:03 ` Jason Gunthorpe
2025-04-02 13:53 ` Jani Nikula
2025-04-02 14:41 ` Simona Vetter
2025-04-02 16:34 ` Jason Gunthorpe
2025-04-01 19:28 ` Jani Nikula [this message]
2025-03-31 15:42 ` Linus Torvalds
2025-04-01 12:34 ` Jani Nikula
2025-03-29 1:01 ` pr-tracker-bot
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=87a58z3cmn.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jgg@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox