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 1096F11C5 for ; Wed, 8 Apr 2015 16:41:01 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 08 Apr 2015 07:41:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,544,1422950400"; d="scan'208";a="710645021" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by orsmga002.jf.intel.com with ESMTP; 08 Apr 2015 07:41:00 -0700 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.95]) by irsmsx105.ger.corp.intel.com ([169.254.7.2]) with mapi id 14.03.0224.002; Wed, 8 Apr 2015 15:40:59 +0100 From: "Butler, Siobhan A" To: Neil Horman Thread-Topic: [dpdk-dev] tools brainstorming Thread-Index: AQHQYx105wa2dYsDE0GLqygeszi7351DCqJggAAA4wCAABdqUIAAAQKAgAApIdA= Date: Wed, 8 Apr 2015 14:40:59 +0000 Message-ID: <0C5AFCA4B3408848ADF2A3073F7D8CC86D58FDBF@IRSMSX109.ger.corp.intel.com> References: <3571725.20GtF5MAnU@xps13> <0C5AFCA4B3408848ADF2A3073F7D8CC86D58F9C2@IRSMSX109.ger.corp.intel.com> <20150408114339.GA22959@hmsreliant.think-freely.org> <0C5AFCA4B3408848ADF2A3073F7D8CC86D58FB64@IRSMSX109.ger.corp.intel.com> <20150408131105.GD22959@hmsreliant.think-freely.org> In-Reply-To: <20150408131105.GD22959@hmsreliant.think-freely.org> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Wed, 08 Apr 2015 14:41:02 -0000 > -----Original Message----- > From: Neil Horman [mailto:nhorman@tuxdriver.com] > Sent: Wednesday, April 8, 2015 2:11 PM > To: Butler, Siobhan A > Cc: Thomas Monjalon; dev@dpdk.org > Subject: Re: [dpdk-dev] tools brainstorming >=20 > On Wed, Apr 08, 2015 at 12:16:10PM +0000, Butler, Siobhan A wrote: > > > > > > > -----Original Message----- > > > From: Neil Horman [mailto:nhorman@tuxdriver.com] > > > Sent: Wednesday, April 8, 2015 12:44 PM > > > To: Butler, Siobhan A > > > Cc: Thomas Monjalon; dev@dpdk.org > > > Subject: Re: [dpdk-dev] tools brainstorming > > > > > > On Wed, Apr 08, 2015 at 10:43:53AM +0000, Butler, Siobhan A wrote: > > > > Hi all, > > > > To add to the tools brainstorming - I propose we use the following > > > > Coding > > > Standards as the basis of guidelines on coding style going forward. > > > > The style outlined below is in alignment with the current > > > > convention used > > > for the majority of the project. > > > > Any thoughts/suggestions or feedback welcome. > > > > Thanks > > > > Siobhan :) > > > > > > > > > > > > > > > > > > > > Coding Style > > > > ~~~~~~~~~~ > > > > > > > > Description > > > > ----------- > > > > > > > > This document specifies the preferred style for source files in > > > > the DPDK > > > source tree. > > > > It is based on the Linux Kernel coding guidelines and the FreeBSD > > > > 7.2 Kernel Developer's Manual (see man style(9)), but was heavily > > > > modified for > > > the needs of the DPDK. Many of the style rules are implicit in the > examples. > > > > Be careful to check the examples before assuming that style is > > > > silent on an > > > issue. > > > > > > > > General Guidelines > > > > ------------------ > > > > > > > > The rules and guidelines given in this document cannot cover every > > > situation, so the following general guidelines should be used as a fa= llback: > > > > The code style should be consistent within each individual file, > > > > and within each file in a given directory or module - in the case > > > > of creating new > > > files The primary reason for coding standards is to increase code > > > readability and comprehensibility, therefore always use whatever > > > option will make the code easiest to read. > > > > > > > > The following more specific recommendations apply to all sections, > > > > both for > > > C and assembly code: > > > > Line length is recommended to be not more than 80 characters, > > > > including comments. [Tab stop size should be assumed to be at > > > > least 4- > > > characters wide] Indentation should be to no more than 3 levels deep. > > > > NOTE The above are recommendations, and not hard limits. However, > > > > it is > > > expected that the recommendations should be followed in all but the > > > rarest situations. > > > > C Comment Style > > > > > > > > Usual Comments > > > > -------------- > > > > > > > > These comments should be used in normal cases. To document a > > > > public > > > API, a doxygen-like format must be used: refer to Doxygen > Documentation. > > > > /* > > > > * VERY important single-line comments look like this. > > > > */ > > > > > > > > /* Most single-line comments look like this. */ > > > > > > > > /* > > > > * Multi-line comments look like this. Make them real sentences. = Fill > > > > * them so they look like real paragraphs. > > > > */ > > > > > > > > License Header > > > > -------------- > > > > > > > > Each file should begin with a special comment tag which will > > > > contain the > > > appropriate copyright and license for the file (Generally BSD License= ). > > > > After any copyright header, a blank line should be left before any > > > > other > > > contents, e.g. include statements in a C file. > > > > > > > > > > This can become very confusing. There already is a LICENSE.GPL and > > > LICENSE.LGPL file at the top of the project, allowing others to > > > insert their own licenses within their files can make it difficult > > > for end user to determine if it is legally safe to use a given projec= t. > > > > > > I'd suggest instead that contributions be disallowed from including > > > license files in their code, relying instead on only a single > > > license at the top of the project (which should likely be BSD or LGPL= , since > we're shipping a library). > > > > > > IANAL, but it seems to me to be dangerous to do anything else. For > > > example, all the code that is dual licensed in the library (like > > > rte_pci_dev_ids.h). It allows for a BSD or GPL license. If someone > > > builds dpdk as a DSO and distributes it under the former, every > > > application that links against that re-distribution may arguably > > > itself become GPL licensed. While I'm personally fine with that, I > > > can see it as being a big deal to some end users. Unifying the > > > license makes the re-distribution license issue more clear for everyo= ne. > > > > > > Neil > > > > > > Input appreciated Neil thank you, would it be best to include this in o= ne of > the community conference calls? > > IANAL either ( yet at least :) ) - we can certainly consult with someon= e who > has the expertise. > > If others are interested in discussing this we can get added to the age= nda > for an upcoming call. > > > > Is more detailed explanation/notice on the licensing structure required= ? > > Thanks, > > Siobhan > > > If you want to discuss it on the community call I think that would be fin= e, > certainly, but it seems that on this forum is the real place to encourage > conversation. Its recorded for posterity, and is open to the entire > community, all we need are people to speak up. >=20 > Neil Fair enough - no issue with that either.=20 The license section aside, do you think the coding style is ok? S >=20 > > > >