From: SF Markus Elfring <elfring@users.sourceforge.net>
To: Julia Lawall <julia.lawall@lip6.fr>, cocci@systeme.lip6.fr
Cc: Gilles Muller <Gilles.Muller@lip6.fr>,
Himanshu Jha <himanshujha199640@gmail.com>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Michal Marek <michal.lkml@markovi.net>,
Nicolas Palix <nicolas.palix@imag.fr>,
LKML <linux-kernel@vger.kernel.org>,
kernel-janitors@vger.kernel.org
Subject: Re: Coccinelle: zalloc-simple: Delete function "kmem_cache_alloc" from SmPL rules
Date: Thu, 1 Feb 2018 11:17:33 +0100 [thread overview]
Message-ID: <22276745-4723-4391-4460-07f0820ae85b@users.sourceforge.net> (raw)
In-Reply-To: <alpine.DEB.2.20.1802011040110.3135@hadrien>
>> The function "kmem_cache_alloc" was specified despite of the technical
>> detail that this function does not get a parameter passed which would
>> correspond to such a size information.
>>
>> Thus remove it from the first two SmPL rules and omit the rule "r4".
>
> Nack.
I find such a rejection surprising once more.
> It should be supported by the size determined in another way.
I am curious on how our different views could be clarified further
for this special software situation.
* Do we agree that a proper size determination is essential for every
condition in the discussed SmPL rules together with forwarding
this information?
* How can a name be ever relevant (within the published SmPL approach)
for a function when it was designed in the way that it should generally
work without a size parameter?
Regards,
Markus
WARNING: multiple messages have this Message-ID (diff)
From: SF Markus Elfring <elfring@users.sourceforge.net>
To: Julia Lawall <julia.lawall@lip6.fr>, cocci@systeme.lip6.fr
Cc: Gilles Muller <Gilles.Muller@lip6.fr>,
Himanshu Jha <himanshujha199640@gmail.com>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Michal Marek <michal.lkml@markovi.net>,
Nicolas Palix <nicolas.palix@imag.fr>,
LKML <linux-kernel@vger.kernel.org>,
kernel-janitors@vger.kernel.org
Subject: Re: Coccinelle: zalloc-simple: Delete function "kmem_cache_alloc" from SmPL rules
Date: Thu, 01 Feb 2018 10:17:33 +0000 [thread overview]
Message-ID: <22276745-4723-4391-4460-07f0820ae85b@users.sourceforge.net> (raw)
In-Reply-To: <alpine.DEB.2.20.1802011040110.3135@hadrien>
>> The function "kmem_cache_alloc" was specified despite of the technical
>> detail that this function does not get a parameter passed which would
>> correspond to such a size information.
>>
>> Thus remove it from the first two SmPL rules and omit the rule "r4".
>
> Nack.
I find such a rejection surprising once more.
> It should be supported by the size determined in another way.
I am curious on how our different views could be clarified further
for this special software situation.
* Do we agree that a proper size determination is essential for every
condition in the discussed SmPL rules together with forwarding
this information?
* How can a name be ever relevant (within the published SmPL approach)
for a function when it was designed in the way that it should generally
work without a size parameter?
Regards,
Markus
next prev parent reply other threads:[~2018-02-01 10:17 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-26 21:40 [PATCH v2] Coccinelle: kzalloc-simple: Add all zero allocating functions Himanshu Jha
2017-12-26 21:40 ` [Cocci] " Himanshu Jha
2017-12-26 21:52 ` Julia Lawall
2017-12-26 21:52 ` [Cocci] " Julia Lawall
2017-12-29 17:22 ` Masahiro Yamada
2017-12-29 17:22 ` [Cocci] " Masahiro Yamada
2017-12-29 17:49 ` Julia Lawall
2017-12-29 17:49 ` [Cocci] " Julia Lawall
2018-01-02 14:25 ` Rename the SmPL script “kzalloc-….cocci”? SF Markus Elfring
2018-01-02 14:25 ` SF Markus Elfring
2018-01-02 14:28 ` Julia Lawall
2018-01-02 14:28 ` [Cocci] " Julia Lawall
2018-01-02 14:28 ` Julia Lawall
2018-01-02 14:38 ` SF Markus Elfring
2018-01-02 14:38 ` SF Markus Elfring
2018-01-02 14:43 ` Julia Lawall
2018-01-02 14:43 ` [Cocci] " Julia Lawall
2018-01-02 14:43 ` Julia Lawall
2018-01-02 15:00 ` SF Markus Elfring
2018-01-02 15:00 ` SF Markus Elfring
2018-01-08 9:55 ` SF Markus Elfring
2018-01-08 9:55 ` SF Markus Elfring
2018-01-03 11:55 ` [PATCH] Coccinelle: Rename the script for a transformation of memory allocations SF Markus Elfring
2018-01-03 11:55 ` SF Markus Elfring
2018-01-03 12:02 ` Julia Lawall
2018-01-03 12:02 ` [Cocci] " Julia Lawall
2018-01-03 12:02 ` Julia Lawall
2018-01-03 12:13 ` SF Markus Elfring
2018-01-03 12:13 ` SF Markus Elfring
2018-01-03 12:17 ` Julia Lawall
2018-01-03 12:17 ` [Cocci] " Julia Lawall
2018-01-03 12:17 ` Julia Lawall
2018-01-03 12:31 ` SF Markus Elfring
2018-01-03 12:31 ` SF Markus Elfring
2018-01-03 12:40 ` Julia Lawall
2018-01-03 12:40 ` [Cocci] " Julia Lawall
2018-01-03 12:40 ` Julia Lawall
2018-01-03 12:45 ` SF Markus Elfring
2018-01-03 12:45 ` SF Markus Elfring
2018-01-04 8:36 ` SF Markus Elfring
2018-01-04 8:36 ` SF Markus Elfring
2018-01-04 8:54 ` Julia Lawall
2018-01-04 8:54 ` [Cocci] " Julia Lawall
2018-01-04 8:54 ` Julia Lawall
2018-01-04 9:43 ` SF Markus Elfring
2018-01-04 9:43 ` SF Markus Elfring
2018-01-17 16:47 ` [v2] Coccinelle: zalloc-simple: Safer transformations with SmPL SF Markus Elfring
2018-01-17 16:47 ` SF Markus Elfring
2018-01-19 16:14 ` Coccinelle: zalloc-simple: Checking consequences from the usage of at signs in Python strings SF Markus Elfring
2018-01-19 16:14 ` SF Markus Elfring
2018-01-19 16:18 ` Julia Lawall
2018-01-19 16:18 ` [Cocci] " Julia Lawall
2018-01-19 16:18 ` Julia Lawall
2018-01-19 16:43 ` SF Markus Elfring
2018-01-19 16:43 ` SF Markus Elfring
2018-01-24 8:41 ` SF Markus Elfring
2018-01-24 8:41 ` SF Markus Elfring
2018-01-31 17:28 ` [v2] Coccinelle: zalloc-simple: Delete function “kmem_cache_alloc” from SmPL rules SF Markus Elfring
2018-01-31 17:28 ` [Cocci] " SF Markus Elfring
2018-01-31 17:28 ` [v2] Coccinelle: zalloc-simple: Delete function =?UTF-8?B?4oCca21lbV9jYWNoZV9hbGxvY SF Markus Elfring
2018-01-31 17:38 ` [v2] Coccinelle: zalloc-simple: Delete function “kmem_cache_alloc” from SmPL rules Julia Lawall
2018-01-31 17:38 ` [Cocci] " Julia Lawall
2018-01-31 17:38 ` =?UTF-8?Q?Re=3A_=5Bv2=5D_Coccinelle=3A_zalloc-simple=3A_Delete_function_=E2=80=9Ckmem=5Fcache=5Fallo Julia Lawall
2018-01-31 17:53 ` [v2] Coccinelle: zalloc-simple: Delete function “kmem_cache_alloc” from SmPL rules SF Markus Elfring
2018-01-31 17:53 ` [v2] Coccinelle: zalloc-simple: Delete function =?UTF-8?B?4oCca21lbV9jYWNoZV9hbGxvY SF Markus Elfring
2018-02-01 9:35 ` [PATCH] Coccinelle: zalloc-simple: Delete function "kmem_cache_alloc" from SmPL rules SF Markus Elfring
2018-02-01 9:35 ` SF Markus Elfring
2018-02-01 9:40 ` Julia Lawall
2018-02-01 9:40 ` [Cocci] " Julia Lawall
2018-02-01 9:40 ` Julia Lawall
2018-02-01 10:17 ` SF Markus Elfring [this message]
2018-02-01 10:17 ` SF Markus Elfring
2018-02-01 10:27 ` Julia Lawall
2018-02-01 10:27 ` [Cocci] " Julia Lawall
2018-02-01 10:27 ` Julia Lawall
2018-02-01 11:00 ` SF Markus Elfring
2018-02-01 11:00 ` SF Markus Elfring
2018-02-03 7:22 ` Coccinelle: zalloc-simple: Checking consistency for " SF Markus Elfring
2018-02-03 7:22 ` SF Markus Elfring
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=22276745-4723-4391-4460-07f0820ae85b@users.sourceforge.net \
--to=elfring@users.sourceforge.net \
--cc=Gilles.Muller@lip6.fr \
--cc=cocci@systeme.lip6.fr \
--cc=himanshujha199640@gmail.com \
--cc=julia.lawall@lip6.fr \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.lkml@markovi.net \
--cc=nicolas.palix@imag.fr \
--cc=yamada.masahiro@socionext.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.