From: Jani Nikula <jani.nikula@linux.intel.com>
To: Francois Dugast <francois.dugast@intel.com>
Cc: intel-xe@lists.freedesktop.org,
Lucas De Marchi <lucas.demarchi@intel.com>,
Matthew Brost <matthew.brost@intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Michal Wajdeczko <michal.wajdeczko@intel.com>
Subject: Re: [PATCH v3] drm/xe: Use fault injection infrastructure to find issues at probe time
Date: Thu, 26 Sep 2024 14:57:01 +0300 [thread overview]
Message-ID: <87ed561vci.fsf@intel.com> (raw)
In-Reply-To: <ZvVJKGc_ltNgYDsl@fdugast-desk>
On Thu, 26 Sep 2024, Francois Dugast <francois.dugast@intel.com> wrote:
> On Thu, Sep 26, 2024 at 12:43:59PM +0300, Jani Nikula wrote:
>> On Wed, 25 Sep 2024, Francois Dugast <francois.dugast@intel.com> wrote:
>> > +/*
>> > + * The ALLOW_ERROR_INJECTION() macro is added to conditionally skip execution at
>> > + * runtime and use a provided return value, in order to test errors paths in the
>> > + * callers. The requirements for the error injectable functions are not strictly
>> > + * fullfilled but this is acceptable because the caller only propagates the error
>> > + * up the stack without cleanup of resources potentially allocated here.
>> > + */
>>
>> I'm curious on the details of "The requirements for the error injectable
>> functions are not strictly fullfilled". It's repeated many times, but
>> not explained. Maybe I'd like the info spoon fed to me instead of having
>> to figure it out for myself. ;)
>
> Understandable! I will make it more explicit in the next revision. Any
> suggestion to avoid the duplication?
All I can think of is adding a single, more thorough explanation comment
about the approach to error injection somewhere suitable (*), and then
have short comments referencing that.
/* See xxx for details on error injection. */
or something.
BR,
Jani.
*) Where, I don't know...
--
Jani Nikula, Intel
next prev parent reply other threads:[~2024-09-26 11:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-25 15:55 [PATCH v3] drm/xe: Use fault injection infrastructure to find issues at probe time Francois Dugast
2024-09-26 9:43 ` Jani Nikula
2024-09-26 11:46 ` Francois Dugast
2024-09-26 11:57 ` Jani Nikula [this message]
2024-09-26 13:06 ` Lucas De Marchi
2024-09-26 13:32 ` Jani Nikula
2024-09-26 18:35 ` Rodrigo Vivi
2024-09-26 15:54 ` ✓ CI.Patch_applied: success for drm/xe: Use fault injection infrastructure to find issues at probe time (rev3) Patchwork
2024-09-26 15:55 ` ✓ CI.checkpatch: " Patchwork
2024-09-26 15:55 ` ✗ CI.KUnit: 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=87ed561vci.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=francois.dugast@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=matthew.brost@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 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.