From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by dpdk.org (Postfix) with ESMTP id 32FE11B7E2 for ; Wed, 17 Apr 2019 18:52:57 +0200 (CEST) Received: by mail-pl1-f171.google.com with SMTP id w23so12307804ply.4 for ; Wed, 17 Apr 2019 09:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=S5l3MC400YKG0Els3fRcrY6DSFIXcg0RWOkDSCSKk1o=; b=DWMLMpvywdbW7uNxwXGedRkgKdTCd8cTfqqSiMHOm4qGJl3/eaaKm3B0KpjlR51XQB aWTVQuWxlhzjpW9FpAvFJl8rHBTT5I8zVseY9RPedSF8iyqnmhqNGLjwYFpVWydD7h6z DhxepRZ4/Pf2m8UcfoB7slIcZXFkFNPoFxqNwTeAVU3wUFtitY98HSEfzYC6I3FvPbcO GSyYlzoNJ0hdyUEH3CeA2+d9Cu+jh6J8T3H/YwPycbcWmLj7Ju7idraRxzdp+7GhUeDK SVLXEEurhGUuSivf7Rj0vJhqQO9Rq7XMPq7EsNRqOe05iATJnxg8+wW0K13NwCpl0315 845g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=S5l3MC400YKG0Els3fRcrY6DSFIXcg0RWOkDSCSKk1o=; b=ZTuiQtdQSMpF9AZLYqD/CVqCttMjH6kgxwa995GOgwEH679gIFv0srHO5f1cZdKssG 7denjRbbLecAyhPZILSw/1Br4UEhRSWSCJxGxyolxwb5ZP7a30nWMKMxx6/r56DSslMF XjaS2mABhR49yHNvlJF49qQPj6gWmxyyCqDhbQFHf3+Lkchtyi4mZyf40ZULnd8m+i6x fNgsOeetEnF3v/+cgBw3C54yscQizFaGNSTSMc59emxelm4ilYUs2DuFNIYHwUfe4bsK cMC7NxGc00RyXue4lkQ9l27F8IrXXgLkvrmW2qU0EIePzwIRnJ+7+1Ww5QrOSwY0GK9R OcLA== X-Gm-Message-State: APjAAAXAfFj5SDhvEpYQ4hyUsPJQOkpX9FXgNECtigYtls948+hcpPop 0dX4h+zyJJ1FqLTxI/aw/Yoqvw== X-Google-Smtp-Source: APXvYqwsMTdLSR2gTyrB/m35uUKu0QRWxe7WXUPhJz2hPkRWO8ix3iPAWeRk1H1nKzGOX0icsPBLvQ== X-Received: by 2002:a17:902:8a81:: with SMTP id p1mr91069600plo.106.1555519975965; Wed, 17 Apr 2019 09:52:55 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id f22sm33415330pgv.45.2019.04.17.09.52.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Apr 2019 09:52:55 -0700 (PDT) Date: Wed, 17 Apr 2019 09:52:37 -0700 From: Stephen Hemminger To: Bruce Richardson Cc: Honnappa Nagarahalli , "dev@dpdk.org" , "Ananyev, Konstantin" , "thomas@monjalon.net" , Ray Kinsella , nd Message-ID: <20190417095237.225bbfae@hermes.lan> In-Reply-To: <20190417083637.GB1890@bricha3-MOBL.ger.corp.intel.com> References: <20190417083637.GB1890@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] ABI and inline functions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 16:52:57 -0000 On Wed, 17 Apr 2019 09:36:38 +0100 Bruce Richardson wrote: > > > > Coming to 1), I think DPDK cannot provide ABI compatibility unless all the inline functions are converted to normal functions and symbol versioning is done for those (not bothering about performance). > > > I disagree. I think even in the case of #1, we should be able to manage > some changes without breaking ABI. > > > In this context, does it make sense to say that we will maintain API > > compatibility rather than saying ABI compatibility? This will also send > > the right message to the end users. > > > I would value ABI compatibility much higher than API compatibility. If > someone is recompiling the application anyway, making a couple of small > changes (large rework is obviously a different issue) to the code should > not be a massive issue, I hope. On the other hand, ABI compatibility is > needed to allow seamless update from one version to another, and it's that > ABI compatiblity that allows distro's to pick up our latest and greatest > versions. Agree with Bruce. What is most important about API is that the function should change signature if behavior changes. I.e catch API changes at compile time (not runtime). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 18C6AA00E6 for ; Wed, 17 Apr 2019 18:53:00 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B3AA81B7E7; Wed, 17 Apr 2019 18:52:58 +0200 (CEST) Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by dpdk.org (Postfix) with ESMTP id 32FE11B7E2 for ; Wed, 17 Apr 2019 18:52:57 +0200 (CEST) Received: by mail-pl1-f171.google.com with SMTP id w23so12307804ply.4 for ; Wed, 17 Apr 2019 09:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=S5l3MC400YKG0Els3fRcrY6DSFIXcg0RWOkDSCSKk1o=; b=DWMLMpvywdbW7uNxwXGedRkgKdTCd8cTfqqSiMHOm4qGJl3/eaaKm3B0KpjlR51XQB aWTVQuWxlhzjpW9FpAvFJl8rHBTT5I8zVseY9RPedSF8iyqnmhqNGLjwYFpVWydD7h6z DhxepRZ4/Pf2m8UcfoB7slIcZXFkFNPoFxqNwTeAVU3wUFtitY98HSEfzYC6I3FvPbcO GSyYlzoNJ0hdyUEH3CeA2+d9Cu+jh6J8T3H/YwPycbcWmLj7Ju7idraRxzdp+7GhUeDK SVLXEEurhGUuSivf7Rj0vJhqQO9Rq7XMPq7EsNRqOe05iATJnxg8+wW0K13NwCpl0315 845g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=S5l3MC400YKG0Els3fRcrY6DSFIXcg0RWOkDSCSKk1o=; b=ZTuiQtdQSMpF9AZLYqD/CVqCttMjH6kgxwa995GOgwEH679gIFv0srHO5f1cZdKssG 7denjRbbLecAyhPZILSw/1Br4UEhRSWSCJxGxyolxwb5ZP7a30nWMKMxx6/r56DSslMF XjaS2mABhR49yHNvlJF49qQPj6gWmxyyCqDhbQFHf3+Lkchtyi4mZyf40ZULnd8m+i6x fNgsOeetEnF3v/+cgBw3C54yscQizFaGNSTSMc59emxelm4ilYUs2DuFNIYHwUfe4bsK cMC7NxGc00RyXue4lkQ9l27F8IrXXgLkvrmW2qU0EIePzwIRnJ+7+1Ww5QrOSwY0GK9R OcLA== X-Gm-Message-State: APjAAAXAfFj5SDhvEpYQ4hyUsPJQOkpX9FXgNECtigYtls948+hcpPop 0dX4h+zyJJ1FqLTxI/aw/Yoqvw== X-Google-Smtp-Source: APXvYqwsMTdLSR2gTyrB/m35uUKu0QRWxe7WXUPhJz2hPkRWO8ix3iPAWeRk1H1nKzGOX0icsPBLvQ== X-Received: by 2002:a17:902:8a81:: with SMTP id p1mr91069600plo.106.1555519975965; Wed, 17 Apr 2019 09:52:55 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id f22sm33415330pgv.45.2019.04.17.09.52.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Apr 2019 09:52:55 -0700 (PDT) Date: Wed, 17 Apr 2019 09:52:37 -0700 From: Stephen Hemminger To: Bruce Richardson Cc: Honnappa Nagarahalli , "dev@dpdk.org" , "Ananyev, Konstantin" , "thomas@monjalon.net" , Ray Kinsella , nd Message-ID: <20190417095237.225bbfae@hermes.lan> In-Reply-To: <20190417083637.GB1890@bricha3-MOBL.ger.corp.intel.com> References: <20190417083637.GB1890@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] ABI and inline functions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190417165237.XMT4pCKq6aLcur8GI2FwmbRQv6uaCb5BWYIHQM9OKCM@z> On Wed, 17 Apr 2019 09:36:38 +0100 Bruce Richardson wrote: > > > > Coming to 1), I think DPDK cannot provide ABI compatibility unless all the inline functions are converted to normal functions and symbol versioning is done for those (not bothering about performance). > > > I disagree. I think even in the case of #1, we should be able to manage > some changes without breaking ABI. > > > In this context, does it make sense to say that we will maintain API > > compatibility rather than saying ABI compatibility? This will also send > > the right message to the end users. > > > I would value ABI compatibility much higher than API compatibility. If > someone is recompiling the application anyway, making a couple of small > changes (large rework is obviously a different issue) to the code should > not be a massive issue, I hope. On the other hand, ABI compatibility is > needed to allow seamless update from one version to another, and it's that > ABI compatiblity that allows distro's to pick up our latest and greatest > versions. Agree with Bruce. What is most important about API is that the function should change signature if behavior changes. I.e catch API changes at compile time (not runtime).