<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 21, 2023 at 11:54 AM David Marchand <<a href="mailto:david.marchand@redhat.com">david.marchand@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jun 20, 2023 at 5:05 PM Bruce Richardson<br>
<<a href="mailto:bruce.richardson@intel.com" target="_blank">bruce.richardson@intel.com</a>> wrote:<br>
><br>
> On Tue, Jun 20, 2023 at 04:33:15PM +0200, Thomas Monjalon wrote:<br>
> > 20/06/2023 11:03, Bruce Richardson:<br>
> > > On Tue, Jun 20, 2023 at 10:48:50AM +0200, David Marchand wrote:<br>
> > > > On Tue, Jun 20, 2023 at 10:45 AM Bruce Richardson<br>
> > > > <<a href="mailto:bruce.richardson@intel.com" target="_blank">bruce.richardson@intel.com</a>> wrote:<br>
> > > > > > > > > I notice the change in behaviour for enabling the deprecated libs. Is there<br>
> > > > > > > > > any other change in behaviour for current users?<br>
> > > > > > > ><br>
> > > > > > > > The only change I see, is that this implementation breaks enabling<br>
> > > > > > > > deprecated libs via disable_libs.<br>
> > > > > > > > It may break existing developer build directory and maybe some<br>
> > > > > > > > packaging scripts, this is why I am a bit puzzled.<br>
> > > > > > > ><br>
> > > > > > > > Relooking at the disable_libs option current implementation, it seems<br>
> > > > > > > > backward to pass a disable_libs option when you want to build some<br>
> > > > > > > > deprecated library.<br>
> > > > > > > > It is more straightforward to request building libraries via<br>
> > > > > > > > -Denable_libs=<deprecated_lib> explicitly or -Denable_libs=*<br>
> > > > > > > > implicitly.<br>
> > > > > > > ><br>
> > > > > > > > But again, we may be breaking something for people who relied on this behavior.<br>
> > > > > > > ><br>
> > > > > > ><br>
> > > > > > > That's what I expected, and I think that is ok. I just wanted to check that<br>
> > > > > > > the change in behaviour was only for the deprecated libs case.<br>
> > > > > ><br>
> > > > > > Thomas, wdyt?<br>
> > > > > > It requires some release note, at least.<br>
> > > > > ><br>
> > > > > I am assuming this is not targetting this release though, right? Assuming<br>
> > > > > 23.11, we can put in a deprecation note informing of the change ahead of<br>
> > > > > time too.<br>
> > > ><br>
> > > > I was hoping to get it in this release.<br>
> > > > But I am fine with postponing and announcing the change beforehand.<br>
> > > ><br>
> > > Given the fact that we are likely changing behaviour, and the fact that the<br>
> > > deprecated libs makes it more complicated than the drivers one (since we<br>
> > > have always on, default on and default off cases to consider), I think it's<br>
> > > best we don't rush this.<br>
> ><br>
> > I'm not sure what is the best behaviour.<br>
> > I tend to think such options should be simple to understand<br>
> > with only 3 cases:<br>
> > - no option -> default<br>
> > - enable option -> only core mandatory and listed libraries<br>
> > - disable option -> all but the listed libraries<br>
> > It looks simpler to forbid having both enable and disable libraries.<br>
> ><br>
> > Would you be open to change the behaviour of the drivers options?<br>
> ><br>
><br>
> [reducing CC list a bit]<br>
><br>
> As a further follow-up, I really think we need to move slowly and more<br>
> carefully on this. While I can see the simplicity in disallowing the two<br>
> options to be specified, depending on how we go about choosing the<br>
> enabling of the deprecated libs, we may want to keep support for allowing<br>
> both.<br>
<br>
I agree, we need more time on this topic, sorry for being pushy earlier :-).<br>
<br>
<br>
><br>
> Specifically, my current concern/thinking is:<br>
> * David points out that using the "disabled_libs" options may not make the<br>
> most logic sense for *enabling* deprecated libs.<br>
> * While that is true, I think the usability of enabling them via<br>
> "enabled_libs" could be pretty terrible - unless we start adding more<br>
> complications. Specifically, if someone wants to just enable KNI in the<br>
> build using "enable_libs", specifying "-Denable_libs=kni" will not do<br>
> what they want - sure it will enable kni, but will disable dozens of<br>
> other parts of DPDK.<br>
> * Therefore, I think keeping the disabling of deprecated parts of DPDK via<br>
> disabled_libs is easier on users - though agreed it is slightly less<br>
> logical. However, if we forbid using enabled and disabled options<br>
> together, that would mean that to switch to enabled libs style, the user<br>
> has to set both enabled libs, *and* clear the default disabled libs option<br>
> of the deprecated ones.<br>
> * Therefore, right now I'm tending more towards something like the status<br>
> quo - disabling deprecated via disable option, but allowing both enable<br>
> and disable options together. This hasn't caused us issues with drivers<br>
> thus far, so I'd be hopeful for using it for libs.<br>
<br>
Mixing enable/disable_drivers has been possible since the introduction<br>
of enable_drivers.<br>
Looking at the code, it is unclear the intention was to make them exclusive.<br>
Is there no usecase for using both options in some soc configuration?<br>
Juraj, do you have an opinion?<br>
<br></blockquote><div><br></div><div>I seem to remember that there wasn't any intention of using them together - I think I did it this way because it was essentially "free" (i.e. the ability to use them together was an extra feature on top of what we needed).</div><div><br></div><div>The SoC considerations were for cross compilation between Arm microarchitectures/SoCs - use enable_drivers mainly to enable only a handful of relevant drivers for small SoC's when building on a server grade SoC. The same applies for disable_drivers - the server grade SoC where we're building may have extra dependencies that we may not want/need on the target (possibly server-grade) system. They don't need to be used in conjunction in these scenarios.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
><br>
> The other alternative, is we come up with:<br>
> * another scheme for managing deprecated libs<br>
> * a special keyword for enabled libs to cover the default case, that one<br>
> can use to add on the deprecated libs, without having to call out each<br>
> and every other optional library.<br>
<br>
I think a separate option to control deprecated libraries would be better.<br>
This option would control whether the deprecation libs are part of the<br>
optional libraries list.<br>
The optional libraries list would then be evaluated according to<br>
enable/disable_libs.<br>
<br>
I'll try this to see how it behaves.<br>
<br>
<br>
-- <br>
David Marchand<br>
<br>
</blockquote></div></div>