DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: David Marchand <david.marchand@redhat.com>, <dev@dpdk.org>,
	<bluca@debian.org>
Subject: Re: [PATCH v3] build: select optional libraries
Date: Tue, 20 Jun 2023 16:01:25 +0100	[thread overview]
Message-ID: <ZJG/RYUs7RI5iUhy@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <23115010.6Emhk5qWAg@thomas>

On Tue, Jun 20, 2023 at 04:33:15PM +0200, Thomas Monjalon wrote:
> 20/06/2023 11:03, Bruce Richardson:
> > On Tue, Jun 20, 2023 at 10:48:50AM +0200, David Marchand wrote:
> > > On Tue, Jun 20, 2023 at 10:45 AM Bruce Richardson
> > > <bruce.richardson@intel.com> wrote:
> > > > > > > > I notice the change in behaviour for enabling the deprecated libs. Is there
> > > > > > > > any other change in behaviour for current users?
> > > > > > >
> > > > > > > The only change I see, is that this implementation breaks enabling
> > > > > > > deprecated libs via disable_libs.
> > > > > > > It may break existing developer build directory and maybe some
> > > > > > > packaging scripts, this is why I am a bit puzzled.
> > > > > > >
> > > > > > > Relooking at the disable_libs option current implementation, it seems
> > > > > > > backward to pass a disable_libs option when you want to build some
> > > > > > > deprecated library.
> > > > > > > It is more straightforward to request building libraries via
> > > > > > > -Denable_libs=<deprecated_lib> explicitly or -Denable_libs=*
> > > > > > > implicitly.
> > > > > > >
> > > > > > > But again, we may be breaking something for people who relied on this behavior.
> > > > > > >
> > > > > >
> > > > > > That's what I expected, and I think that is ok. I just wanted to check that
> > > > > > the change in behaviour was only for the deprecated libs case.
> > > > >
> > > > > Thomas, wdyt?
> > > > > It requires some release note, at least.
> > > > >
> > > > I am assuming this is not targetting this release though, right? Assuming
> > > > 23.11, we can put in a deprecation note informing of the change ahead of
> > > > time too.
> > > 
> > > I was hoping to get it in this release.
> > > But I am fine with postponing and announcing the change beforehand.
> > > 
> > Given the fact that we are likely changing behaviour, and the fact that the
> > deprecated libs makes it more complicated than the drivers one (since we
> > have always on, default on and default off cases to consider), I think it's
> > best we don't rush this.
> 
> I'm not sure what is the best behaviour.
> I tend to think such options should be simple to understand
> with only 3 cases:
> - no option -> default
> - enable option -> only core mandatory and listed libraries
> - disable option -> all but the listed libraries
> It looks simpler to forbid having both enable and disable libraries.
> 
> Would you be open to change the behaviour of the drivers options?
> 

[reducing CC list a bit]

As a further follow-up, I really think we need to move slowly and more
carefully on this. While I can see the simplicity in disallowing the two
options to be specified, depending on how we go about choosing the
enabling of the deprecated libs, we may want to keep support for allowing
both.

Specifically, my current concern/thinking is:
* David points out that using the "disabled_libs" options may not make the
  most logic sense for *enabling* deprecated libs.
* While that is true, I think the usability of enabling them via
  "enabled_libs" could be pretty terrible - unless we start adding more
  complications. Specifically, if someone wants to just enable KNI in the
  build using "enable_libs", specifying "-Denable_libs=kni" will not do
  what they want - sure it will enable kni, but will disable dozens of
  other parts of DPDK.
* Therefore, I think keeping the disabling of deprecated parts of DPDK via
  disabled_libs is easier on users - though agreed it is slightly less
  logical. However, if we forbid using enabled and disabled options
  together, that would mean that to switch to enabled libs style, the user
  has to set both enabled libs, *and* clear the default disabled libs option
  of the deprecated ones.
* Therefore, right now I'm tending more towards something like the status
  quo - disabling deprecated via disable option, but allowing both enable
  and disable options together. This hasn't caused us issues with drivers
  thus far, so I'd be hopeful for using it for libs.

The other alternative, is we come up with:
* another scheme for managing deprecated libs
* a special keyword for enabled libs to cover the default case, that one
  can use to add on the deprecated libs, without having to call out each
  and every other optional library.

  parent reply	other threads:[~2023-06-20 15:02 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-10 16:48 [PATCH 0/5] Extend optional libraries list David Marchand
2021-11-10 16:48 ` [PATCH 1/5] ci: test build with minimum configuration David Marchand
2021-11-16 17:06   ` Thomas Monjalon
2021-11-16 20:39     ` David Marchand
2021-11-16 21:47       ` Thomas Monjalon
2021-11-10 16:48 ` [PATCH 2/5] build: make GRO/GSO optional David Marchand
2021-11-16 17:11   ` Thomas Monjalon
2021-11-10 16:48 ` [PATCH 3/5] build: make metrics libraries optional David Marchand
2021-11-16 17:12   ` Thomas Monjalon
2021-11-10 16:48 ` [PATCH 4/5] build: make pdump optional David Marchand
2021-11-16 17:14   ` Thomas Monjalon
2021-11-10 16:48 ` [PATCH 5/5] build: select optional libraries David Marchand
2021-11-10 17:34   ` Bruce Richardson
2021-11-16 17:25     ` Thomas Monjalon
2021-11-17 10:47       ` Bruce Richardson
2021-11-17 11:27         ` David Marchand
2022-01-07 16:13           ` Morten Brørup
2022-01-07 16:47             ` Stephen Hemminger
2021-11-10 17:34 ` [PATCH 0/5] Extend optional libraries list Bruce Richardson
2021-11-17 11:28 ` [PATCH v2 " David Marchand
2021-11-17 11:28   ` [PATCH v2 1/5] ci: test minimum configuration David Marchand
2021-11-17 11:50     ` Thomas Monjalon
2021-11-17 13:38     ` Aaron Conole
2021-11-17 11:28   ` [PATCH v2 2/5] build: make GRO/GSO optional David Marchand
2021-11-17 11:28   ` [PATCH v2 3/5] build: make metrics libraries optional David Marchand
2021-11-17 11:28   ` [PATCH v2 4/5] build: make pdump optional David Marchand
2021-11-17 11:28   ` [PATCH v2 5/5] build: select optional libraries David Marchand
2023-06-16  7:14     ` [PATCH v3] " David Marchand
2023-06-16  9:42       ` Bruce Richardson
2023-06-19  8:00         ` David Marchand
2023-06-19 14:11       ` David Marchand
2023-06-19 14:26         ` Bruce Richardson
2023-06-20  8:31           ` David Marchand
2023-06-20  8:35             ` Bruce Richardson
2023-06-20  8:38               ` David Marchand
2023-06-20  8:44                 ` Bruce Richardson
2023-06-20  8:48                   ` David Marchand
2023-06-20  9:03                     ` Bruce Richardson
2023-06-20 14:33                       ` Thomas Monjalon
2023-06-20 14:40                         ` Bruce Richardson
2023-06-20 15:01                         ` Bruce Richardson [this message]
2023-06-21  9:54                           ` David Marchand
2023-06-21 10:49                             ` Bruce Richardson
2023-06-21 11:35                               ` Morten Brørup
2023-06-22  9:27                             ` Juraj Linkeš
2023-06-21 17:00     ` [PATCH v4 0/4] Select " David Marchand
2023-06-21 17:00       ` [PATCH v4 1/4] kni: move IOVA build check David Marchand
2023-06-22  8:37         ` Bruce Richardson
2023-06-21 17:00       ` [PATCH v4 2/4] build: rename enabled libraries list David Marchand
2023-06-22  8:38         ` Bruce Richardson
2023-06-21 17:00       ` [PATCH v4 3/4] build: select deprecated libraries David Marchand
2023-06-22  8:43         ` Bruce Richardson
2023-06-22  8:50           ` Bruce Richardson
2023-06-23  9:35           ` David Marchand
2023-06-23 11:04             ` Bruce Richardson
2023-06-23 11:15               ` Morten Brørup
2023-06-23 11:19                 ` Bruce Richardson
2023-06-23 11:32                   ` Morten Brørup
2023-06-28 12:10                     ` David Marchand
2023-06-21 17:00       ` [PATCH v4 4/4] build: select optional libraries David Marchand
2023-06-22  8:49         ` Bruce Richardson
2023-06-22  9:09       ` [PATCH v4 0/4] Select " Bruce Richardson
2023-06-22 16:41         ` Thomas Monjalon
2023-06-28 13:20     ` [PATCH v5 0/2] " David Marchand
2023-06-28 13:20       ` [PATCH v5 1/2] build: select deprecated libraries David Marchand
2023-06-29 12:44         ` Aaron Conole
2023-06-28 13:20       ` [PATCH v5 2/2] build: select optional libraries David Marchand
2023-06-28 14:48       ` [PATCH v5 0/2] Select " Morten Brørup
2023-07-17 12:54         ` Bruce Richardson
2021-11-17 11:52   ` [PATCH v2 0/5] Extend optional libraries list Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZJG/RYUs7RI5iUhy@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=bluca@debian.org \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).