From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id CD45C5A2D for ; Tue, 14 Apr 2015 16:52:59 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 14 Apr 2015 07:52:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,576,1422950400"; d="scan'208";a="679918185" Received: from bricha3-mobl3.ger.corp.intel.com ([10.243.20.33]) by orsmga001.jf.intel.com with SMTP; 14 Apr 2015 07:52:56 -0700 Received: by (sSMTP sendmail emulation); Tue, 14 Apr 2015 15:52:55 +0025 Date: Tue, 14 Apr 2015 15:52:55 +0100 From: Bruce Richardson To: Thomas Monjalon Message-ID: <20150414145255.GC3296@bricha3-MOBL3> References: <3571725.20GtF5MAnU@xps13> <0C5AFCA4B3408848ADF2A3073F7D8CC86D58F9C2@IRSMSX109.ger.corp.intel.com> <2232884.6IKBPajdgE@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2232884.6IKBPajdgE@xps13> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] tools brainstorming X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 14:53:01 -0000 On Wed, Apr 08, 2015 at 06:16:12PM +0200, Thomas Monjalon wrote: > 2015-04-08 15:53, Wiles, Keith: > > One of the biggest problems with any style is helping the developer > > maintain the style. Using some tool does help and I have used astyle > > before, not bad code formatter. Here is a few that seem to be reasonable. > > > > http://astyle.sourceforge.net/ > > > > http://uncrustify.sourceforge.net/ > > > > http://sourceforge.net/projects/gcgreatcode/ > > I'm not sure it's a good idea to convert the codebase automatically. > The coding style must be a reference for new patches and they must be > automatically checked with a dedicated checkpatch tool. > By forbidding patches which don't comply, the codebase will be naturally > converted over time. > I'd like to see us document the existing style as much as possible before changing it. That saves any conversion issues. In cases where multiple styles are used, we can initially go with the more prevalent one. > I didn't review this proposal yet. > My first comment is that it's too long to read :) > 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? /Bruce