From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A77CB433E2; Mon, 27 Nov 2023 17:26:02 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 27D9C40648; Mon, 27 Nov 2023 17:26:02 +0100 (CET) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by mails.dpdk.org (Postfix) with ESMTP id 1BBB7402A3; Mon, 27 Nov 2023 17:26:01 +0100 (CET) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 9E5303200B0E; Mon, 27 Nov 2023 11:25:59 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 27 Nov 2023 11:26:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1701102359; x=1701188759; bh=PoP70IglSQSprxSENgjXySCw6V5kpfGhUVl Hx6T2JO4=; b=ZsO7XVVgIexEuNMViOzslxHeBH18WVa0kffO0wPDKSUqsuIlCG/ bY6Lw5h1jWpIxKYnLAjKB2CYnua5wiz6F/td2ueFEGu5uFF6vxMRiVnyDOVq/sLb BP9rQ7wZgHAOfMcXi4+tPjWd/pttRqg9/n2/NhuEgk8WZVySdxfB87AlRATVSJ7h i5cTUG+yfRNPWpgFC33lLvE5d9sLk6Hok3RbDRM2X5Fx1w0Nicm+lY6oCZGwssf8 Uo2WygmGtpPCdMiKhvFxgwMJOELez+3fbUET4Tza3B99ed0Zl5EtC7VNKVMuCLIK cZm8osPB+FV5UQNmXKyykJLXRQh3O32pw6A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1701102359; x=1701188759; bh=PoP70IglSQSprxSENgjXySCw6V5kpfGhUVl Hx6T2JO4=; b=J7BvRHbv4HX8SQAyzN11jEQyIYWNRkR3BZD3rdY2Ue1deeu37sn P46iyDPwxPLURf8LlTCij6hRr7CifcFf9NqQxI6P2mt7cJOkcJFkFvTgvvAidpNG FWjc0+HTu51ezS3dB0nJYd1StiHSmd3/M1nOAHPDxtkSvUd+WQgK4c5Q0HX/MmEu rYB2n7sP/odjjRbTjeLDZ+LQEFhBpCMAodN9YtMRI8dIKa5p8v0TDECIMNvHYHUc BhPbSto8IIAOU1pnaSPL60XqVjePrXMXgAjE8s5DXVkPcjl03uGWT3Tp1HTQCvQ/ 8/1B6J9VxqYeCJLNOGnp+cm0DAtQ192+GSA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeiuddgkeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeejudffiefgjeeljeejudefjeelgfeuhffgudeivdeludetheeg heehveelueffueenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhgihhtlhgrsgdrtg homhdpmhgvshhonhdrsghuihhlugenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Nov 2023 11:25:57 -0500 (EST) From: Thomas Monjalon To: Morten =?ISO-8859-1?Q?Br=F8rup?= , jerinj@marvell.com Cc: dev@dpdk.org, techboard@dpdk.org, bruce.richardson@intel.com, Jerin Jacob Subject: Re: [dpdk-dev] [PATCH v2] doc: define qualification criteria for external library Date: Mon, 27 Nov 2023 17:25:55 +0100 Message-ID: <6668305.V25eIC5XRa@thomas> In-Reply-To: References: <20230928051648.562526-1-jerinj@marvell.com> <98CBD80474FA8B44BF855DF32C47DC35E9F043@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 20/11/2023 18:46, Jerin Jacob: > On Sun, Nov 19, 2023 at 2:23=E2=80=AFPM Morten Br=C3=B8rup wrote: > > > From: Jerin Jacob [mailto:jerinjacobk@gmail.com] > > > On Fri, Nov 17, 2023 at 1:57=E2=80=AFPM Morten Br=C3=B8rup > > > > > From: Jerin Jacob [mailto:jerinjacobk@gmail.com] > > > > > On Thu, Sep 28, 2023 at 11:10=E2=80=AFAM wro= te: > > > > > > From: Jerin Jacob > > > > > > +- **Free availability**: The library must be freely available = to > > > > > build in either source or binary > > > > > > + form, with a preference for source form. > > > > > > > > Suggest adding: > > > > > > > > - **Free use and distribution license**: The library must be freely > > > available to use and distribute without any attached conditions. > > > > > > > > We must require a BSD-like license, to ensure that DPDK as a whole > > > (including 3rd party libraries) remains BSD licensed, and can be used > > > in commercial (closed source) applications. > > > > > > As far as I understand, The initial scope of was =E2=80=9Cfree availa= bility=E2=80=9D > > > for building. > > > Free distribution is much wider scope. I don't think, current external > > > libraries[1] have free distribution rights. > > > [1] > > > https://github.com/DPDK/dpdk/blob/main/doc/guides/gpus/cuda.rst > > > https://gitlab.com/nvidia/headers/cuda-individual/cudart/- > > > /blob/main/LICENSE?ref_type=3Dheads > > > > I didn't mean the library source code; I only meant the library in bina= ry form. > > > > It is nice if the library's header files may be distributed too, but I = don't see it as a requirement, especially if they are freely available else= where (preferably without imposing additional restrictions on the ability t= o use and distribute the library in binary form). > > > > How about this instead: > > > > - **License permitting free use and distribution in binary form**: > > The library's license must allow free and unconditional use and distrib= ution of the library in binary form. >=20 > Distribution and unconditional use is not the case for existing > library dependencies such as > https://gitlab.com/nvidia/headers/cuda-individual/cudart/-/blob/main/LICE= NSE?ref_type=3Dheads >=20 > So I am not sure, Which is the correct thing to do. Maybe we can > discuss more in tech board meeting if there are no other comments in > mailing list on this topic. I don't think we should make mandatory to have rights of redistribution. To me, being to download and install the dependency without any restriction is enough *for a driver*. If distribution of the dependency is restricted, then the driver will be disabled by the distro. It is not our problem I think. And I agree we must have stricter requirements for libraries dependencies. I am OK to mandate free distribution for such library dependencies. > > We might want lawyers to verify the wording when we have agreed on our = intentions. > > > > > I am fine with either way, Feedback from others? [...] > > > > > > +- **Code readability**: When the depended library is optional, > > > use > > > > > stubs to reduce the ``ifdef`` > > > > > > + clutter to enable better code readability. > > > > > > > > Why does everyone keep insisting that stubs make code more readable? > > > Sometimes #ifdef is better. > > > > > > Could you share a case where when #ifdefs is better(Just to understand > > > the view).? > > > > If an external library provides some simple functions, and a group (i.e= =2E a subset) of functions in a DPDK library depends on that external libra= ry, then it might be more readable if those functions are enabled/disabled = as a group in the DPDK library rather than individually. > > > > E.g. the external library provides functions for statistical processing= , and the DPDK library can be built with or without statistics, depending o= n using the external library or not. If the DPDK library is built without s= tatistics, it should not register statistics availability towards a managem= ent module (e.g. telemetry) if it is not really implemented within the DPDK= library (because the underlying functions are stubs). > > > > It might also be a matter of personal preferences. When reviewing some = source code, an #ifdef makes the availability of an underlying function per= fectly clear. Blindly calling a function (of an external library) doesn't r= eally show if the function is implemented for real, or just a stub. >=20 > In general theme in DPDK code base that we are trying to avoid a lot > of #ifdef in a given C file. > Instead, we are doing following scheme. >=20 > https://github.com/DPDK/dpdk/blob/main/drivers/ml/cnxk/meson.build#L84 > https://github.com/DPDK/dpdk/blob/main/drivers/ml/cnxk/meson.build#L60 > https://github.com/DPDK/dpdk/blob/main/drivers/ml/cnxk/mvtvm_ml_stubs.c >=20 > > My opinion on this might be tainted by my preference for building from = scratch. The distro people might see it very differently! >=20 > Yeah. I don't have a strong opinion, I can change to following, if > there are no comments on this. Or we can discuss more in TB meeting if > there are no review comments in mailing list on this topic. >=20 > **Code readability**: When the depended library is optional, use > either stubs or ``#ifdef`` consistently, not a mix of both, to ensure > code readability. >=20 > > > > Please use something like this instead: > > > > > > > > - **Code readability**: When the depended library is optional, use > > > either stubs or ``#ifdef`` consistently, not a mix of both, to ensure > > > code readability. We should better focus on code organisation for technical reasons: we don't want to mix OS-specific code in a common file. That's why stubs are preferred to implement functions with OS-specific incl= udes, etc. If it's just a matter of disabling some code, #ifdef is fine.