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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.