From: Jacob Keller <jacob.e.keller@intel.com>
To: Markus Elfring <Markus.Elfring@web.de>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>, <cocci@inria.fr>
Subject: Re: [cocci] Evolution of transformation processes?
Date: Mon, 10 Mar 2025 11:23:07 -0700 [thread overview]
Message-ID: <47c3c014-ae5e-4f91-8c0e-2f57fd084ea1@intel.com> (raw)
In-Reply-To: <f1caf085-043e-4b30-ac0d-56a111e36a78@web.de>
On 3/8/2025 1:45 AM, Markus Elfring wrote:
>> In particular, about my project:
>>
>> We have a repository with code that is originally designed to be shared
>> among multiple drivers. This code uses constructs like "ice_free", or
>> typecasts required for C++, but which the Linux kernel does not. We need
>> the code we ultimately contribute to the kernel to follow the kernel
>> guidelines.
>>
>> The semantic patches are applied automatically as part of the build
>> process, and not something we commit. This process was done in order to
>> try and align what we distribute in our out-of-tree releases with what
>> we end up submitting to the kernel community.
>
> Thanks for such background information.
>
>
>> This usage is likely different from many projects where the patches are
>> used to find and commit fixed code. In our case, committing the result
>> (and thus being able to manually tweak it) are not viable because that
>> would break other downstream consumers of this code internally.
>
> * How much do you still need to recheck results from automated data processing?
>
We do have some monitoring to check if the output changes when we update
the coccinelle version, but otherwise don't manually check each time we
run the same script.
> * Would you like to achieve reasonably low system failure rates?
>
In our setup, we only use patches which have very low failure rates.
This is a requirement because they are applied automatically and
expected to be consistent and catch all the changes we care about. In
most cases, the failure rate must be zero or else the resulting code
will not compile.
prev parent reply other threads:[~2025-03-10 18:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-07 0:43 [cocci] behavior change in semantic patches since c36b51ffc889 ("don't drop down on single statement") Jacob Keller
2025-03-07 0:55 ` Julia Lawall
2025-03-07 20:24 ` Jacob Keller
2025-03-07 10:47 ` [cocci] behavior change in semantic patches since c36b51ffc889 … Markus Elfring
2025-03-07 20:53 ` Jacob Keller
2025-03-07 22:47 ` Jacob Keller
2025-03-08 9:07 ` Markus Elfring
2025-03-10 18:34 ` Jacob Keller
2025-03-11 9:10 ` Markus Elfring
2025-03-08 8:39 ` Markus Elfring
2025-03-10 18:27 ` Jacob Keller
2025-03-11 9:26 ` Przemek Kitszel
2025-03-08 9:45 ` [cocci] Evolution of transformation processes? Markus Elfring
2025-03-10 18:23 ` Jacob Keller [this message]
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=47c3c014-ae5e-4f91-8c0e-2f57fd084ea1@intel.com \
--to=jacob.e.keller@intel.com \
--cc=Markus.Elfring@web.de \
--cc=cocci@inria.fr \
--cc=przemyslaw.kitszel@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.