Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Senna Tschudin <peter.senna@linux.intel.com>
To: "Zbigniew Kempczyński" <zbigniew.kempczynski@intel.com>
Cc: Kamil Konieczny <kamil.konieczny@linux.intel.com>,
	igt-dev@lists.freedesktop.org, ryszard.knop@intel.com,
	lucas.demarchi@intel.com, katarzyna.piecielska@intel.com,
	Jonathan Cavitt <jonathan.cavitt@intel.com>
Subject: Re: [PATCH i-g-t v4 1/2] lib/igt_kmemleak: library to interact with kmemleak
Date: Tue, 25 Feb 2025 19:06:17 +0100	[thread overview]
Message-ID: <5770f7ad-9a63-494a-a780-90520abc1977@linux.intel.com> (raw)
In-Reply-To: <d07d932d-bfb3-4cf4-b12c-a885c62867a9@linux.intel.com>

Hi Zbigniew,

On 25.02.2025 14:46, Peter Senna Tschudin wrote:
> Hi Zbigniew,
> 
> On 11.02.2025 17:17, Zbigniew Kempczyński wrote:
> [...]
> 
>>
>> I'm looking at the code and I have impression this should be part of
>> the runner, not igt library. Do I understand correctly that your
>> code will be used by the runner only and not by the tests?
>>
>> Regarding your above question, I think runner should use as much as
>> minimal from lib/ directory, because this is collection of functions
>> designed for tests, not for runner. I think generic code like data
>> structures (lists) are fine, but not the others. Imagine you'll
>> incidentally try to use igt_require() - follow the call and see
>> the pitfall there.
>>
>> So if my understanding is correct and this code should be part of the
>> runner only your test might be moved to the runner_tests.c.
>>
>> BTW please rebase on top of current master, there were changes in
>> the runner/settings.c file that affects this series.
> 
> I sent V5 a few moments ago and I included the AMD folks who sent a patch
> to add kmemleaks integration as a library for tests. Please have a look at
> the last comment from AMD explaining why adding a lib for tests:
> 
> https://patchwork.freedesktop.org/series/145011/
> 
> I feel we should work with them to avoid duplication functionality. What
> are your toughs?

I have a proposal: what about extending the kmemleak library to add an
additional option that to accept a test list file pointing to the
tests we want to collect kmemleak reports? At least in theory this will
allow the AMD folks to do what they want. Something like:
 - once: collect kmemleak reports after running all tests
 - each: collect kmemleak reports after running each test
 - file: collect kmemleak reports after each test on the file

Please let me know what you think.

Thanks,

Peter

  reply	other threads:[~2025-02-25 18:06 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-28 15:15 [PATCH i-g-t v4 0/2] Integrate kmemleak scans in igt_runner Peter Senna Tschudin
2025-01-28 15:15 ` [PATCH i-g-t v4 1/2] lib/igt_kmemleak: library to interact with kmemleak Peter Senna Tschudin
2025-01-31 12:34   ` Kamil Konieczny
2025-02-03  9:23     ` Peter Senna Tschudin
2025-02-11 16:17       ` Zbigniew Kempczyński
2025-02-11 19:12         ` Peter Senna Tschudin
2025-02-12  8:36           ` Zbigniew Kempczyński
2025-02-12  9:18             ` Peter Senna Tschudin
2025-02-12 10:01               ` Zbigniew Kempczyński
2025-02-12 13:12                 ` Peter Senna Tschudin
2025-02-12 13:41                   ` Kamil Konieczny
2025-02-12 14:57                     ` Peter Senna Tschudin
2025-02-25 13:46         ` Peter Senna Tschudin
2025-02-25 18:06           ` Peter Senna Tschudin [this message]
2025-01-31 12:38   ` Kamil Konieczny
2025-02-03  9:14     ` Peter Senna Tschudin
2025-02-12 14:26       ` Kamil Konieczny
2025-01-28 15:15 ` [PATCH i-g-t v4 2/2] runner/executor: Integrate igt_kmemleak scans Peter Senna Tschudin
2025-01-31 12:50   ` Kamil Konieczny
2025-02-03  9:10     ` Peter Senna Tschudin
2025-02-12 14:24       ` Kamil Konieczny
2025-02-12 14:53         ` Peter Senna Tschudin
2025-01-28 20:48 ` ✓ i915.CI.BAT: success for Integrate kmemleak scans in igt_runner (rev2) Patchwork
2025-01-28 20:49 ` Patchwork
2025-01-28 20:52 ` ✓ Xe.CI.BAT: " Patchwork
2025-01-29 10:40 ` ✗ Xe.CI.Full: failure " Patchwork
2025-01-29 13:18   ` Peter Senna Tschudin
2025-01-29 11:25 ` ✗ i915.CI.Full: " Patchwork
2025-01-29 13:19   ` Peter Senna Tschudin
2025-01-30  6:18     ` Ravali, JupallyX
2025-01-30  5:26 ` ✓ i915.CI.Full: success " 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=5770f7ad-9a63-494a-a780-90520abc1977@linux.intel.com \
    --to=peter.senna@linux.intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=jonathan.cavitt@intel.com \
    --cc=kamil.konieczny@linux.intel.com \
    --cc=katarzyna.piecielska@intel.com \
    --cc=lucas.demarchi@intel.com \
    --cc=ryszard.knop@intel.com \
    --cc=zbigniew.kempczynski@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