DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Wiles, Keith" <keith.wiles@intel.com>
To: "Wiles, Keith" <keith.wiles@intel.com>,
	Thomas Monjalon <thomas.monjalon@6wind.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] tools brainstorming
Date: Tue, 14 Apr 2015 18:52:51 +0000	[thread overview]
Message-ID: <D152C904.1ADCC%keith.wiles@intel.com> (raw)
In-Reply-To: <D152A63B.1ADAB%keith.wiles@intel.com>



On 4/14/15, 11:19 AM, "Wiles, Keith" <keith.wiles@intel.com> wrote:

>
>
>On 4/14/15, 10:24 AM, "Thomas Monjalon" <thomas.monjalon@6wind.com> wrote:
>
>>2015-04-14 15:52, Bruce Richardson:
>>> On Wed, Apr 08, 2015 at 06:16:12PM +0200, Thomas Monjalon wrote:
>>> > When a consensus is done, it must be added with a patch with custom
>>> > checkpatch addition.
>>> > 
>>> My personal feeling is that we should try and keep checkpatch
>>>modifications to a
>>> minimum. Right now, we can use checkpatch as-is from kernel.org, right?
>>
>>Yes that's something we have to discuss.
>>It should be preferred to avoid "forking" checkpatch.
>>
>>At the moment, I'm using this configuration:
>>
>>	options="$options --max-line-length=100"
>>	options="$options --show-types"
>>	options="$options --ignore=LINUX_VERSION_CODE,FILE_PATH_CHANGES,\
>>	VOLATILE,PREFER_PACKED,PREFER_ALIGNED,PREFER_PRINTF,\
>>	SPLIT_STRING,LINE_SPACING,NEW_TYPEDEFS,COMPLEX_MACRO"
>>
>>	linux/scripts/checkpatch.pl $options
>>
>>I would like to submit a script to run checkpatch with DPDK configuration
>>when the coding rules are clear.
>>
>>However, I've already seen some options which are not enough configurable
>>(don't remember which one). For such corner case, I would see 3 solutions
>>(from the most to the least desired):
>>	- submit a patch to allow more configuration to kernel.org
>>	- give up automatic handling of corner cases
>>	- maintain a fork in scripts/ directory
>Here is the next solution
>	- Stop using checkpatch and use a real tool for formatting code instead.
>If someone uses a tool before commit, then create the patch which does not
>require checkpatch.
>Most of these tools can define an output file or they leave behind the
>original file as a backup or we can see if they have a non-modify mode and
>just points out the problems. As in astyle '--dry-run' can be used, plus
>it saves the original file as XXXXX.orig or you can change the .orig to
>your own value.
>>

Using uncrustify with following config file seems to be very close to what
we have today and removes trailing white spaces. I changed the
indent_with_tabs to 2 instead of 1. I am sure we could even get closer.
The uncrustify creates the updated file into XXXXX.uncrustify which does
not effect the original file. Then you can use meld or some other tool to
view the changes.

http://uncrustify.sourceforge.net/default.cfg


The source is here http://uncrustify.sourceforge.net/ pretty simple
install on my Ubuntu 14.04 machine.

I also installed the amd64 image of UniversalindentGUI. I tried the
ŒUbuntu Software Center¹ version, but it required a bit more effort then
just installing. It appeared the code needed a specific version of a
library I did not track down.

http://uncrustify.sourceforge.net/


It looks like using uncrustify and a config file gives use a tool to
verify the code is formatted correctly before commit and patch create.

Have a look and see what you  think.

  reply	other threads:[~2015-04-14 18:52 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-20 14:51 Thomas Monjalon
2015-03-20 15:07 ` Butler, Siobhan A
2015-03-23 16:18   ` Thomas Monjalon
2015-03-23 16:50     ` Butler, Siobhan A
2015-03-23 17:35     ` Neil Horman
2015-03-23 23:38     ` Matthew Hall
2015-03-20 15:16 ` Neil Horman
2015-03-23 16:22   ` Jim Thompson
2015-03-23 17:44     ` Neil Horman
2015-03-23 21:56       ` Jim Thompson
2015-03-23 23:01         ` Neil Horman
2015-03-23 16:26   ` Thomas Monjalon
2015-03-20 15:18 ` Simon Kågström
2015-03-23 16:29   ` Thomas Monjalon
2015-03-24  8:31     ` Simon Kågström
2015-03-23  8:41 ` Cao, Waterman
2015-03-23 16:18 ` Mcnamara, John
2015-04-08 10:43 ` Butler, Siobhan A
2015-04-08 11:43   ` Neil Horman
2015-04-08 12:16     ` Butler, Siobhan A
2015-04-08 12:20       ` Butler, Siobhan A
2015-04-08 13:11       ` Neil Horman
2015-04-08 14:40         ` Butler, Siobhan A
2015-04-08 15:39           ` Neil Horman
2015-04-08 22:29           ` Jay Rolette
2015-04-08 22:38             ` Stephen Hemminger
2015-04-09 16:31               ` Jay Rolette
2015-04-09 19:16                 ` Neil Horman
2015-04-09 19:38                   ` Jay Rolette
2015-04-09 20:14                     ` Neil Horman
2015-04-09 21:10                     ` Wiles, Keith
2015-04-09 21:23                       ` Stephen Hemminger
2015-04-09 21:29                         ` Wiles, Keith
2015-04-10  0:16                           ` Neil Horman
2015-04-10  0:26                       ` Neil Horman
2015-04-10  1:49                         ` Wiles, Keith
2015-04-10 11:41                           ` Neil Horman
2015-04-10 14:43                             ` Wiles, Keith
2015-04-08 14:16   ` Wiles, Keith
2015-04-14 14:50     ` Bruce Richardson
2015-04-08 15:21   ` Wiles, Keith
2015-04-08 15:53   ` Wiles, Keith
2015-04-08 16:16     ` Thomas Monjalon
2015-04-08 16:25       ` Wiles, Keith
2015-04-08 19:54       ` Butler, Siobhan A
2015-04-14 14:21         ` Bruce Richardson
2015-04-14 14:38           ` Neil Horman
2015-04-14 14:47             ` Thomas Monjalon
2015-04-14 14:54               ` Bruce Richardson
2015-04-14 14:52       ` Bruce Richardson
2015-04-14 15:24         ` Thomas Monjalon
2015-04-14 16:19           ` Wiles, Keith
2015-04-14 18:52             ` Wiles, Keith [this message]
2015-04-08 18:16   ` Stephen Hemminger
2015-04-08 18:58     ` Matthew Hall
2015-04-08 22:12       ` Stephen Hemminger
2015-04-08 19:51     ` Butler, Siobhan A
2015-04-14 15:29     ` Bruce Richardson
2015-04-08 21:55   ` Don Provan
2015-04-13 15:02   ` Neil Horman
2015-04-13 23:44     ` Stephen Hemminger
2015-04-16 10:49   ` Thomas Monjalon

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=D152C904.1ADCC%keith.wiles@intel.com \
    --to=keith.wiles@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=thomas.monjalon@6wind.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;
as well as URLs for NNTP newsgroup(s).