DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	Bruce Richardson <bruce.richardson@intel.com>,
	Luca Boccassi <bluca@debian.org>,
	Thomas Monjalon <thomas@monjalon.net>, dpdk-dev <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] checkpatch: re-enable warnings about split long strings
Date: Thu, 28 Mar 2019 19:03:10 +0000	[thread overview]
Message-ID: <a4d38408-b4a9-422e-edd4-d7f4082942ad@intel.com> (raw)
Message-ID: <20190328190310.D_ZRWAcHBXeGB7q3BLVvJ4ucT925QsaChN0UUrIWkcU@z> (raw)
In-Reply-To: <92660560-a08f-662c-293c-91d1a988e5f3@intel.com>

On 3/28/2019 7:02 PM, Ferruh Yigit wrote:
> On 10/3/2017 11:56 AM, adrien.mazarguil at 6wind.com (Adrien Mazarguil) wrote:
>> On Tue, Oct 03, 2017 at 11:38:13AM +0100, Bruce Richardson wrote:
>>> On Mon, Oct 02, 2017 at 06:21:06PM +0200, Adrien Mazarguil wrote:
>>>> On Mon, Oct 02, 2017 at 02:46:24PM +0100, Bruce Richardson wrote:
>>>>> On Mon, Oct 02, 2017 at 01:53:17PM +0200, Adrien Mazarguil wrote:
>>>>>> Hi Stephen,
>>>>>>
>>>>>> On Fri, Sep 29, 2017 at 08:37:49AM -0700, Stephen Hemminger wrote:
>>>>>>> The Linux kernel style policy about strings is that strings should
>>>>>>> be always put on one line. This makes sense since a typical use case
>>>>>>> is for a user to type the error message into a search engine or
>>>>>>> grep, and it won't be found if split across lines.  This patch just
>>>>>>> re-enables that check.
>>>>>>>
>>>>>>> Yes, lots of DPDK code now splits strings, that doesn't make it
>>>>>>> right.
>>>>>>>
>>>>>>> Signed-off-by: Stephen Hemminger <sthemmin at microsoft.com> ---
>>>>>>> devtools/checkpatches.sh | 1 - 1 file changed, 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
>>>>>>> index a56c41a301c0..3e6081dd673e 100755 ---
>>>>>>> a/devtools/checkpatches.sh +++ b/devtools/checkpatches.sh @@ -44,7
>>>>>>> +44,6 @@ options="$options --show-types" options="$options
>>>>>>> --ignore=LINUX_VERSION_CODE,FILE_PATH_CHANGES,\
>>>>>>> VOLATILE,PREFER_PACKED,PREFER_ALIGNED,PREFER_PRINTF,\
>>>>>>> PREFER_KERNEL_TYPES,BIT_MACRO,CONST_STRUCT,\
>>>>>>> -SPLIT_STRING,LONG_LINE_STRING,\
>>>>>>> LINE_SPACING,PARENTHESIS_ALIGNMENT,NETWORKING_BLOCK_COMMENT_STYLE,\
>>>>>>> NEW_TYPEDEFS,COMPARISON_TO_NULL"
>>>>>>
>>>>>> I'm not sure, given that the main reason for splitting strings in the
>>>>>> first place is to avoid LONG_LINE_STRING warnings, I think we must
>>>>>> choose between the two options. If split strings are not allowed, then
>>>>>> long lines must be.
>>>>>>
>>>>>> Since checkpatches.sh is used by various automated scripts to complain
>>>>>> loudly about problems in submissions, the above change prevents
>>>>>> maintainers from writing long string at all (can't split and can't go
>>>>>> past 80 columns).
>>>>>>
>>>>>> As a result, they will be tempted to cripple their code with nasty
>>>>>> workarounds to shut up checkpatches.sh, we don't want that to happen.
>>>>>>
>>>>>> Also I think the reasons stated by original commit cf75514c8e2e are
>>>>>> still relevant. My vote would be to keep things as is.
>>>>>>
>>>>> In my experience, checkpatch is smart enough to recognise when a long
>>>>> line overflows the 80 character limit because of a single long string,
>>>>> so the two options are not mutually exclusive. In other words, long
>>>>> lines are not allowed except in the case where shortening the line
>>>>> involves splitting a string. There may be a small amount of work in
>>>>> getting checkpatch happy, i.e. by putting the string on a line on it's
>>>>> own, but we can indeed have our cake and eat it too in this case.
>>>>
>>>> I can't seem to get around warnings without ignoring either SPLIT_STRING or
>>>> LONG_LINE_STRING as of Linux v4.14-rc3's checkpatch.pl. I think you can only
>>>> get around them by fooling it somehow. You really need to ignore at least
>>>> LONG_LINE_STRING to meet the requirements of the commit log.
>>>>
>>>> However SPLIT_STRING still looks necessary to address part of cf75514c8e2e
>>>> ("devtools: ignore warning on long log string"):
>>>>
>>>>  "...lines that make use of PRIx64 with string concatenation will still be
>>>>   flagged if the beginning of the last string fragment begins after the 80
>>>>   character threshold."
>>>>
>>>> It's not all that uncommon in my opinion.
>>>>
>>> If you have PRIx64 in it, it's not part of a literal string you would
>>> grep, so it's reasonable to split there. The user cannot know what the
>>> specific %x formatting character used is.
>>
>> I agree, however in that case checkpatch would complain because our
>> configuration doesn't specify to ignore SPLIT_STRING since there is no comma
>> separator when concatenating them.
>>
>> My point is that the occasional exception is still necessary for split
>> strings, that ignoring LONG_LINE_STRING must remain either way and
>> unnecessary warnings cause more harm than good (they need to be worked
>> around if we enforce this rule).
>>
>> In short, long/split strings acceptability assessment should be left to
>> reviewers, as it cannot be automated in all cases through checkpatch.pl.
>>
> 
> This patch is waiting in patchwork for a long time now.
> 
> My experience is same with Adrien's, if 'LONG_LINE_STRING' is not ignored, it
> will complain about long log messages, so removing 'LONG_LINE_STRING'
> contradicts with the reason of the patch described in the commit log.
> 
> Perhaps it can be an option to remove only 'SPLIT_STRING' from ignore list, to
> detect split messages.
> 
> But overall, I am updating this patch as "Change Requested", if there is a
> demand for ignoring 'SPLIT_STRING' please send a new version.
> 

Sorry for the noise, I keep forgetting this, for reference the patch mentioned:
https://patches.dpdk.org/patch/29438/


  parent reply	other threads:[~2019-03-28 19:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-29 15:37 Stephen Hemminger
2017-10-02 10:01 ` Luca Boccassi
2017-10-02 11:53 ` Adrien Mazarguil
2017-10-02 13:46   ` Bruce Richardson
2017-10-02 16:21     ` Adrien Mazarguil
2017-10-03 10:38       ` Bruce Richardson
2017-10-03 10:56         ` Adrien Mazarguil
2019-03-28 19:02           ` Ferruh Yigit
2019-03-28 19:02             ` Ferruh Yigit
2019-03-28 19:03             ` Ferruh Yigit [this message]
2019-03-28 19:03               ` Ferruh Yigit

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=a4d38408-b4a9-422e-edd4-d7f4082942ad@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=adrien.mazarguil@6wind.com \
    --cc=bluca@debian.org \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /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;
as well as URLs for NNTP newsgroup(s).