public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: igt-dev@lists.freedesktop.org
Subject: Re: [PATCH i-g-t 00/16] igt: clean up typedef usage, use for_each_output() more
Date: Tue, 14 Apr 2026 19:09:32 +0300	[thread overview]
Message-ID: <ad5mvKQeTMCkgSI_@intel.com> (raw)
In-Reply-To: <cd012ba649468272cbd655b47c98b108ebb38efd@intel.com>

On Tue, Apr 14, 2026 at 06:51:39PM +0300, Jani Nikula wrote:
> On Tue, 14 Apr 2026, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > On Tue, Apr 14, 2026 at 10:14:20AM +0300, Jani Nikula wrote:
> >> This series spiraled into a few things:
> >> 
> >> - use typedefs like igt_foo_t more consistently instead of struct
> >>   igt_foo
> >
> > I'm not a huge fan of the typedefs but getting rid of them now
> > would involve a gargantuan patch. So best to just accept them
> > I guess.
> 
> Yeah, in general I'd reserve typedefs for opaque types that you really
> aren't supposed to look at. It feels weird to have some foo_t and then
> go on to access its members implicitly assuming it's a struct.

Even for opaque types the non-typedef seems a bit better to me
because you can't really forward declare typedefs without
mentioning the struct anyway.

typdefs aren't even proper types in C, more like aliases. You
can typedef the same underlying type multiple times and then
use any of the typdefs (or the actual type) interchangeably.
The compiler will not even tell you that you're being silly.

> 
> But I think that ship has sailed, and we're better off focusing on
> consistency here.
> 
> And we're just a couple of brainwashed kernel developers avoiding
> typedefs. ;)
> 
> > Series is
> > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Thanks, pushed the lot.
> 
> BR,
> Jani.
> 
> 
> -- 
> Jani Nikula, Intel

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2026-04-14 16:09 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-14  7:14 [PATCH i-g-t 00/16] igt: clean up typedef usage, use for_each_output() more Jani Nikula
2026-04-14  7:14 ` [PATCH i-g-t 01/16] tests: prefer igt_plane_t over struct igt_plane Jani Nikula
2026-04-14  7:14 ` [PATCH i-g-t 02/16] lib/kms: rename struct igt_plane to _igt_plane Jani Nikula
2026-04-14  7:14 ` [PATCH i-g-t 03/16] tests: prefer igt_display_t over struct igt_display Jani Nikula
2026-04-14  7:14 ` [PATCH i-g-t 04/16] lib/kms: rename struct igt_display to _igt_display Jani Nikula
2026-04-14  7:14 ` [PATCH i-g-t 05/16] lib/kms: rename struct igt_crtc to _igt_crtc Jani Nikula
2026-04-14  7:14 ` [PATCH i-g-t 06/16] lib/kms: drop struct igt_colorop definition Jani Nikula
2026-04-14  7:14 ` [PATCH i-g-t 07/16] tests/amdgpu/amd_abm: use for_each_output() Jani Nikula
2026-04-14  7:14 ` [PATCH i-g-t 08/16] tests/amdgpu/amd_hotplug: " Jani Nikula
2026-04-14  7:14 ` [PATCH i-g-t 09/16] tests/amdgpu/amd_subvp: " Jani Nikula
2026-04-14  7:14 ` [PATCH i-g-t 10/16] tests/amdgpu/amd_dp_dsc: " Jani Nikula
2026-04-14  7:14 ` [PATCH i-g-t 11/16] tests/amdgpu/amd_plane: " Jani Nikula
2026-04-14  7:14 ` [PATCH i-g-t 12/16] tests/kms_atomic_transition: " Jani Nikula
2026-04-14  7:14 ` [PATCH i-g-t 13/16] tests/kms_colorop: " Jani Nikula
2026-04-14  7:14 ` [PATCH i-g-t 14/16] tests/kms_content_protection: " Jani Nikula
2026-04-14  7:14 ` [PATCH i-g-t 15/16] tests/kms_getfb: " Jani Nikula
2026-04-14  7:14 ` [PATCH i-g-t 16/16] tests/kms_writeback: " Jani Nikula
2026-04-14  9:59 ` ✓ Xe.CI.BAT: success for igt: clean up typedef usage, use for_each_output() more Patchwork
2026-04-14 10:14 ` ✓ i915.CI.BAT: " Patchwork
2026-04-14 11:11 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-04-14 14:08 ` [PATCH i-g-t 00/16] " Ville Syrjälä
2026-04-14 15:51   ` Jani Nikula
2026-04-14 16:09     ` Ville Syrjälä [this message]
2026-04-14 16:47 ` ✓ i915.CI.Full: success for " Patchwork

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=ad5mvKQeTMCkgSI_@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    /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