From: Jani Nikula <jani.nikula@linux.intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
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 15:21:24 +0300 [thread overview]
Message-ID: <87tt782htn.fsf@intel.com> (raw)
In-Reply-To: <20250331133137.GA263675@nvidia.com>
On Mon, 31 Mar 2025, Jason Gunthorpe <jgg@nvidia.com> wrote:
> Please don't keep it fully isolated to DRM.. This new stuff did find
> an error in the fwctl UAPI headers around uuid_t that had gone unnoticed:
>
> https://lore.kernel.org/all/f6489337-67c7-48c8-b48a-58603ec15328@paulmck-laptop/raw
>
> I think that was a valuable report, you just need to find a way to
> make the tests it runs more acceptable..
The header checks have existed for uapi headers before, including the,
uh, turds, but apparently adding them in drm broke the camel's back.
> FWIW, there is a "trick" I like to use for C header files, just ensure
> that some C file someplace includes each header file first in the
> #include list. It automatically makes the compiler check it is self
> contained naturally. You can get pretty far by paying attention to
> this detail and it costs nothing at build time.
It's a fairly good solution for a lot of cases, but it falls a bit
short. I'd additionally like to ensure:
- Header guards are in place
- There are no kernel-doc warnings
- Headers not associated 1:1 with a .c file are also checked
Finally, the cost of having to keep checking the headers are in fact
included first, and nagging about it in reviews, is not without cost.
BR,
Jani.
--
Jani Nikula, Intel
next prev parent reply other threads:[~2025-04-01 12:21 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 [this message]
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
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=87tt782htn.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=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