From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) by dpdk.org (Postfix) with ESMTP id 5C7C3377A for ; Thu, 9 Apr 2015 00:29:58 +0200 (CEST) Received: by iggg4 with SMTP id g4so52556519igg.0 for ; Wed, 08 Apr 2015 15:29:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=x0LhFDZOMcFudXPR3ZmmdhPtJpPTKistzBtiV6oBOcc=; b=PkPZOzi/IEYiGugl87+cCEolGUV2kTR0y8Ab5r/H0wGj40Ojz7pZnP/vCx6DDmXAfc dnnv7yh13ldENqHGKc0OvdileJroQvQoGIgUwVYdS1AqPP0sunNA4O1fbUY+fGb2of6E 1vhIpw8ZNA7PAICv6R4B2tYhhLN5q78juGGuSAEn5T+rsfHXvtqqc44C4hkorU/1keTd JZpINbcnzu4RR6MbkZM5l9CZcmkjmYElMf+IFf7OuhzF+g+LzaO6xqFTg2nQf7CyUbH/ IbJYZpLCkgneGCr78QD3Zu3DSLEu8ZJ6xK4CTAPxMmwsOFtAxjzWrAFAfDgFDBVGvaEX mtSQ== X-Gm-Message-State: ALoCoQnxXg97Ilpop2sBhSbg+K6d4NQ6nH9mlpD4hNuqI7PCpW2E3LMGNqcUBmQ1mM9vxhNJj9xE X-Received: by 10.50.55.1 with SMTP id n1mr4607748igp.35.1428532197873; Wed, 08 Apr 2015 15:29:57 -0700 (PDT) Received: from [10.255.250.140] ([158.120.0.14]) by mx.google.com with ESMTPSA id b1sm7642624igl.7.2015.04.08.15.29.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Apr 2015 15:29:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jay Rolette X-Mailer: iPhone Mail (12D508) In-Reply-To: <0C5AFCA4B3408848ADF2A3073F7D8CC86D58FDBF@IRSMSX109.ger.corp.intel.com> Date: Wed, 8 Apr 2015 16:29:54 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0FBA33A7-A21E-426F-B44E-32E86F2B23DB@infiniteio.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> <0C5AFCA4B3408848ADF2A3073F7D8CC86D58FDBF@IRSMSX109.ger.corp.intel.com> To: "Butler, Siobhan A" 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 22:29:58 -0000 "C comments" includes //, right? It's been part of the C standard for a long= time now... Sent from my iPhone > On Apr 8, 2015, at 8:40 AM, Butler, Siobhan A = wrote: >=20 >=20 >=20 >> -----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: >>>=20 >>>=20 >>>> -----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 >>>>=20 >>>>> 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 :) >>>>> >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Coding Style >>>>> ~~~~~~~~~~ >>>>>=20 >>>>> Description >>>>> ----------- >>>>>=20 >>>>> 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. >>>>>=20 >>>>> General Guidelines >>>>> ------------------ >>>>>=20 >>>>> The rules and guidelines given in this document cannot cover every >>>> situation, so the following general guidelines should be used as a fall= back: >>>>> 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. >>>>>=20 >>>>> 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 >>>>>=20 >>>>> Usual Comments >>>>> -------------- >>>>>=20 >>>>> 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. >>>>> */ >>>>>=20 >>>>> /* Most single-line comments look like this. */ >>>>>=20 >>>>> /* >>>>> * Multi-line comments look like this. Make them real sentences. Fill= >>>>> * them so they look like real paragraphs. >>>>> */ >>>>>=20 >>>>> License Header >>>>> -------------- >>>>>=20 >>>>> 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. >>>>=20 >>>> 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 project.= >>>>=20 >>>> 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, s= ince >> we're shipping a library). >>>>=20 >>>> 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 everyone= . >>>>=20 >>>> Neil >>>=20 >>>=20 >>> Input appreciated Neil thank you, would it be best to include this in on= e of >> the community conference calls? >>> IANAL either ( yet at least :) ) - we can certainly consult with someone= who >> has the expertise. >>> If others are interested in discussing this we can get added to the agen= da >> for an upcoming call. >>>=20 >>> 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 >>>=20 >>>=20