All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: Re: [PATCH 2/2] drm/xe: drop display/ subdir from include directories
Date: Tue, 23 Jan 2024 19:13:21 +0200	[thread overview]
Message-ID: <87ttn4m0r2.fsf@intel.com> (raw)
In-Reply-To: <663d25vngq6zcee6vupweq7dohhmftpaggtnfl7752sn6qhdao@ypgsfn62skob>

On Tue, 23 Jan 2024, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
> On Mon, Jan 22, 2024 at 07:39:56PM +0200, Jani Nikula wrote:
>>On Mon, 22 Jan 2024, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
>>> the downside of patch 1 is now that core xe code can include any of the
>>> display/ headers, but only xe_display.h is acceptable to keep the
>>> interface sane.
>>
>>I'd say xe_display.h remains the only interface towards xe core, I don't
>>think this patch changes that, and its location doesn't really give any
>>guarantees. It's been a matter of sticking display/ in the include
>>anyway, and enforcing that is a matter of maintainer vigilance.
>
> I just thought the previous split was slightly better: No code in xe
> should include display/ and should rather use the xe_display.[hc]
> interface.
>
> Now with #include "display/xe_display.h" spread throughout the code,
> this could serve as example for people to start including stuff they
> shouldn't.
>
> I'm not entirely opposed, so if you and others agree, please go ahead.

Well, at the moment you can include *anything* from under display/
*without* the prefix, because it's all in the include path. (Although
that will fail for DRM_XE_DISPLAY=n, but does CI even build that combo
regularly?)

I'm fine with dropping this too. I just think it makes it easier to
check that nothing outside of display/ does any displayish things.

Your call.


BR,
Jani.

>
> Lucas De Mrachi
>
>>
>>> Or are you thinking about changing the interface?
>>
>>I agree the interface should be in one file only, but changing the
>>interface is an orthogonal matter (I have no plans atm).
>>
>>BR,
>>Jani.
>>
>>
>>-- 
>>Jani Nikula, Intel

-- 
Jani Nikula, Intel

  reply	other threads:[~2024-01-23 17:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-22 10:14 [PATCH 1/2] drm/xe: move xe_display.[ch] under display/ Jani Nikula
2024-01-22 10:14 ` [PATCH 2/2] drm/xe: drop display/ subdir from include directories Jani Nikula
2024-01-22 16:58   ` Rodrigo Vivi
2024-01-22 17:19   ` Lucas De Marchi
2024-01-22 17:39     ` Jani Nikula
2024-01-23 16:49       ` Lucas De Marchi
2024-01-23 17:13         ` Jani Nikula [this message]
2024-01-30  9:19           ` Jani Nikula
2024-01-30 17:32             ` Lucas De Marchi
2024-01-31 13:47               ` Jani Nikula
2024-01-22 16:59 ` [PATCH 1/2] drm/xe: move xe_display.[ch] under display/ Rodrigo Vivi

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=87ttn4m0r2.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@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 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.