Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: John Harrison <john.c.harrison@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>,
	<Intel-Xe@Lists.FreeDesktop.Org>,
	"Souza, Jose" <jose.souza@intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH v5 1/8] drm/xe/guc: Remove spurious line feed in debug print
Date: Wed, 31 Jul 2024 12:56:30 -0700	[thread overview]
Message-ID: <a9ef6254-f428-47b7-827d-82ec94408ca2@intel.com> (raw)
In-Reply-To: <9306b3ec-3999-468b-8395-dc3b7900ff6f@intel.com>

On 7/30/2024 02:14, Michal Wajdeczko wrote:
>
> On 30.07.2024 01:17, John.C.Harrison@Intel.com wrote:
>> From: John Harrison <John.C.Harrison@Intel.com>
>>
>> Including line feeds at the start of a debug print messes up the
>> output when sent to dmesg. The break actually appears between all the
>> usefu
> typo
>
>> prefix information and the actual string being printed. In this
>> case, each block of data has a very clear start line and an extra
>> delimeter is really not necessary. So don't do it.
>>
>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> there was some discussion about merging this one without a conclusion
>
> [1] https://patchwork.freedesktop.org/patch/601018/?series=135447&rev=1
The last comment was for Mesa people to shout if it would be a problem 
and no-one shouted, so...

However, I would strongly argue that devcoredump exact layout and 
content cannot be considered UABI because it is going to change as the 
driver changes. Some of the information being printed is internal driver 
state. Driver internals can never be UABI. If there are userland tools 
parsing the dump then those tools have to be able to adapt to changing 
core dump formats. There is also the argument that we are still in 
force-probe so there is no fixed UABI yet anyway. So now is the time to 
get the formatting as good as possible before officially going live.

John.


>
>> ---
>>   drivers/gpu/drm/xe/xe_guc_ct.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
>> index beeeb120d1fc..422c3f5c87d8 100644
>> --- a/drivers/gpu/drm/xe/xe_guc_ct.c
>> +++ b/drivers/gpu/drm/xe/xe_guc_ct.c
>> @@ -1515,7 +1515,7 @@ void xe_guc_ct_snapshot_print(struct xe_guc_ct_snapshot *snapshot,
>>   		drm_puts(p, "H2G CTB (all sizes in DW):\n");
>>   		guc_ctb_snapshot_print(&snapshot->h2g, p);
>>   
>> -		drm_puts(p, "\nG2H CTB (all sizes in DW):\n");
>> +		drm_puts(p, "G2H CTB (all sizes in DW):\n");
>>   		guc_ctb_snapshot_print(&snapshot->g2h, p);
>>   
>>   		drm_printf(p, "\tg2h outstanding: %d\n",


  reply	other threads:[~2024-07-31 19:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-29 23:17 [PATCH v5 0/8] drm/xe/guc: Improve quality and robustness of GuC log dumping John.C.Harrison
2024-07-29 23:17 ` [PATCH v5 1/8] drm/xe/guc: Remove spurious line feed in debug print John.C.Harrison
2024-07-30  9:14   ` Michal Wajdeczko
2024-07-31 19:56     ` John Harrison [this message]
2024-07-31 20:14       ` Souza, Jose
2024-08-01 18:14         ` Matthew Brost
2024-08-05 18:18         ` John Harrison
2024-07-29 23:17 ` [PATCH v5 2/8] drm/xe/guc: Copy GuC log prior to dumping John.C.Harrison
2024-07-29 23:17 ` [PATCH v5 3/8] drm/xe/guc: Use a two stage dump for GuC logs and add more info John.C.Harrison
2024-07-29 23:17 ` [PATCH v5 4/8] drm/print: Introduce drm_line_printer John.C.Harrison
2024-07-29 23:17 ` [PATCH v5 5/8] drm/xe/guc: Add a helper function for dumping GuC log to dmesg John.C.Harrison
2024-07-29 23:17 ` [PATCH v5 6/8] drm/xe/guc: Dead CT helper John.C.Harrison
2024-07-29 23:17 ` [PATCH v5 7/8] drm/xe/guc: Dump entire CTB on errors John.C.Harrison
2024-07-29 23:17 ` [PATCH v5 8/8] drm/xe/guc: Add GuC log to devcoredump captures John.C.Harrison
2024-08-04 22:36   ` Matthew Brost
2024-08-05 18:41     ` John Harrison
2024-08-05 20:46       ` Matthew Brost
2024-07-29 23:24 ` ✓ CI.Patch_applied: success for drm/xe/guc: Improve quality and robustness of GuC log dumping (rev3) Patchwork
2024-07-29 23:24 ` ✗ CI.checkpatch: warning " Patchwork
2024-07-29 23:25 ` ✓ CI.KUnit: success " Patchwork
2024-07-29 23:37 ` ✓ CI.Build: " Patchwork
2024-07-29 23:39 ` ✗ CI.Hooks: failure " Patchwork
2024-07-29 23:41 ` ✗ CI.checksparse: warning " Patchwork
2024-07-30  0:00 ` ✓ CI.BAT: success " Patchwork
2024-07-30  3:36 ` ✗ CI.FULL: failure " 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=a9ef6254-f428-47b7-827d-82ec94408ca2@intel.com \
    --to=john.c.harrison@intel.com \
    --cc=Intel-Xe@Lists.FreeDesktop.Org \
    --cc=jose.souza@intel.com \
    --cc=michal.wajdeczko@intel.com \
    --cc=rodrigo.vivi@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