From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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: <xms:FsNkZTQ4AAnra7LZ5q9QkQ4CSToDycLHgytEMzTKlCORupJC3lmKMw>
 <xme:FsNkZUzCfDczynKD_hfskDh-PEW_4HLDeG083bgKcm4UXiPFmd_45LQDZY5CwkYen
 GKdweMxcv_DqYI0wQ>
X-ME-Received: <xmr:FsNkZY1aH7SdBGPqzIgz2dMZwFLly6PkMedjysV1lMpC5ir4Q9-5u_mxLHZXA6CTlSYMeh1AmSYKqLuciMor_sKIbg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeiuddgkeelucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm
 rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc
 ggtffrrghtthgvrhhnpeejudffiefgjeeljeejudefjeelgfeuhffgudeivdeludetheeg
 heehveelueffueenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhgihhtlhgrsgdrtg
 homhdpmhgvshhonhdrsghuihhlugenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgr
 mhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght
X-ME-Proxy: <xmx:FsNkZTCok-FswZns7Lfp8WT8SFF1hF5Uhs-daG_kEzFmuyZKdN3fgA>
 <xmx:FsNkZciAfZ1QSSsTj1gnz18SfumVgSObrQshA-8uo9T2BBHiB-4V2w>
 <xmx:FsNkZXohanmx-H-idrzMiGVUy1Ban8V7ZUJUaHtHgN7H3Hv4xbGdqQ>
 <xmx:F8NkZUdUbXJeX_r4e-5ZykoYtE5kMmG3yUDW59HDGgGcued0qzUBmA>
Feedback-ID: i47234305:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 27 Nov 2023 11:25:57 -0500 (EST)
From: Thomas Monjalon <thomas@monjalon.net>
To: Morten =?ISO-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com>,
 jerinj@marvell.com
Cc: dev@dpdk.org, techboard@dpdk.org, bruce.richardson@intel.com,
 Jerin Jacob <jerinjacobk@gmail.com>
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: <CALBAE1Ntt127gTKTfcvOO4Zy1ojh1ugWzb9DWfqiH5Wa=26xkA@mail.gmail.com>
References: <20230928051648.562526-1-jerinj@marvell.com>
 <98CBD80474FA8B44BF855DF32C47DC35E9F043@smartserver.smartshare.dk>
 <CALBAE1Ntt127gTKTfcvOO4Zy1ojh1ugWzb9DWfqiH5Wa=26xkA@mail.gmail.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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 <mb@smartshare=
systems.com> 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 <jerinj@marvell.com> wro=
te:
> > > > > > From: Jerin Jacob <jerinj@marvell.com>
> > > > > > +- **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.