DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ray Kinsella <mdr@ashroe.eu>
To: Dodji Seketeli <dodji@redhat.com>
Cc: David Marchand <david.marchand@redhat.com>, dev <dev@dpdk.org>,
	Andrzej Ostruszka <aostruszka@marvell.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	Thomas Monjalon <thomas@monjalon.net>,
	Neil Horman <nhorman@tuxdriver.com>,
	Jingjing Wu <jingjing.wu@intel.com>,
	Wenzhuo Lu <wenzhuo.lu@intel.com>,
	Matan Azrad <matan@mellanox.com>,
	Shahaf Shuler <shahafs@mellanox.com>,
	Viacheslav Ovsiienko <viacheslavo@mellanox.com>,
	Jerin Jacob <jerinj@marvell.com>,
	Nithin Dabilpuram <ndabilpuram@marvell.com>,
	Alfredo Cardigliano <cardigliano@ntop.org>,
	Mahipal Challa <mchalla@marvell.com>,
	Cristian Dumitrescu <cristian.dumitrescu@intel.com>,
	"Wang, Haiyue" <haiyue.wang@intel.com>
Subject: Re: [dpdk-dev] [PATCH v2] abi: change references to abi 20.0.1 to abi v21
Date: Thu, 30 Apr 2020 09:23:25 +0100	[thread overview]
Message-ID: <0c7985d0-c0f9-3f25-f617-59e074639406@ashroe.eu> (raw)
In-Reply-To: <86wo5yjxg0.fsf@redhat.com>



On 29/04/2020 13:19, Dodji Seketeli wrote:
> Hello,
> 
> Ray Kinsella <mdr@ashroe.eu> writes:
> 
>> ah ok, the particular system I made the change on was Ubuntu 18.04.2.
>> which is libabigail 1.2.0.
> 
> Whoah, 1.2 is super old.

I have a huge clunking raid'ed "build" server,
that I am pretty conservative about upgrading on v18.04.2 :-)

> In my opinion, one of the hallmarks of static analysis tools (and
> libabigail is just a static analysis framework) is to be able to
> recognize patterns used by developers, as much as we can.
> 
> Because we can't really do that at once, we try to add recognition of
> new patterns (of ABI changes) at every single release.  Furthermore,
> there are some change patterns that ought to be recognized and
> categorized as harmless, whereas some others out to be categorized as
> harmful.  That categorization is also the result of input coming from
> users as you, fine fellows.
> 
> All this to say that with every new version, the number of new supported
> features and bug fixes is potentially big.
> 
> To alleviate that, some distributors update libabigail even in their old
> stable distros, because the value of having an up to date version there
> outweighs the potential drawbacks.

Well it falls into the same category of problems of upgrading compilers.
User's typically build their software build reliably on a given distro version.
(or number of versions). 

If the maintainer upgrades compilers between distro versions, it introduces new 
warnings and errors, and all hell will generally break loose, when the user least expects it. 
They typically expect that mayhem when upgrading to new distro versions. 
Even tools like GNU indent can cause enormous problems. 

I would imagine that most maintainers would be pretty conservative about making
such changes. 

> 
>> Given we still support v19.11 on Ubuntu 18.04.2.
> 
> So maybe that's a discussion worth having with the maintainer of the
> Ubuntu package of Libabigail?

yes - I think it would be an interesting discussion alright.
I imagine the response might be inline with my understanding above.
Let's find out - as we can expect v18.04 to be around for at least another
two years I guess.

Another common way to handle this, is to be really explicit about what 
OS distros DPDK formally supports building on, which will then imply 
we support a small handful of versions of libabigail. 

We then simply say we don't support 18.04 anymore - FD.io VPP are planning 
this formal switch at the moment. 

> 
>> I think it's worthwhile keeping the suppression until v20.11?
> 
> [...]
> 
> David Marchand <david.marchand@redhat.com> writes:
> 
>> In Travis, we currently use libabigail 1.6 (mainly because I did not
>> update to 1.7 when it was released).
> 
> Right, that's probably another way to stay up to date independently from
> the underlying distribution.

You typically don't want to encourage this, you end up with some people
on a newer version, some people on an old version and never upgrading. 

Then you never end up with a consistent view of what mitigations are actually required.
Solving issues, becomes like a game of whack-a-mole. 

> 
> I hope this helps,

It does, greatly thanks. 

> 
> Cheers,
> 

  reply	other threads:[~2020-04-30  8:23 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-20  9:34 [dpdk-dev] [PATCH] " Ray Kinsella
2020-04-20 11:57 ` Ray Kinsella
2020-04-20 12:20   ` David Marchand
2020-04-20 15:25     ` Ray Kinsella
2020-04-22  8:07     ` Ray Kinsella
2020-04-22  8:11       ` David Marchand
2020-04-22  8:18       ` Thomas Monjalon
2020-04-22  8:28         ` Ray Kinsella
2020-04-23  6:41 ` [dpdk-dev] [PATCH v2] " Ray Kinsella
2020-04-24  9:15   ` Thomas Monjalon
2020-04-24 14:10   ` David Marchand
2020-04-24 14:50     ` Ray Kinsella
2020-04-24 15:01       ` David Marchand
2020-04-29 12:19       ` Dodji Seketeli
2020-04-30  8:23         ` Ray Kinsella [this message]
2020-04-27  9:06 ` [dpdk-dev] [PATCH v3] " Ray Kinsella
2020-04-27  9:06   ` Ray Kinsella
2020-04-27 13:45 ` [dpdk-dev] [PATCH v4] " Ray Kinsella
2020-04-27 13:45   ` Ray Kinsella
2020-04-30 10:21 ` [dpdk-dev] [PATCH v5] " Ray Kinsella
2020-04-30 10:27 ` [dpdk-dev] [PATCH v6 1/1] " Ray Kinsella
2020-04-30 10:27   ` Ray Kinsella
2020-05-04 22:23     ` Thomas Monjalon
2020-05-04 22:05   ` 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=0c7985d0-c0f9-3f25-f617-59e074639406@ashroe.eu \
    --to=mdr@ashroe.eu \
    --cc=aostruszka@marvell.com \
    --cc=cardigliano@ntop.org \
    --cc=cristian.dumitrescu@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=dodji@redhat.com \
    --cc=haiyue.wang@intel.com \
    --cc=jerinj@marvell.com \
    --cc=jingjing.wu@intel.com \
    --cc=matan@mellanox.com \
    --cc=mchalla@marvell.com \
    --cc=ndabilpuram@marvell.com \
    --cc=nhorman@tuxdriver.com \
    --cc=shahafs@mellanox.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    --cc=viacheslavo@mellanox.com \
    --cc=wenzhuo.lu@intel.com \
    /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).