From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f194.google.com (mail-wr0-f194.google.com [209.85.128.194]) by dpdk.org (Postfix) with ESMTP id AA29E1B375 for ; Mon, 5 Feb 2018 14:44:59 +0100 (CET) Received: by mail-wr0-f194.google.com with SMTP id w50so29648754wrc.2 for ; Mon, 05 Feb 2018 05:44:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=2N6CS2fvX/5meXayqhTZX1D1m4xxvqwL2vqiRfInLNY=; b=V+l8RvWRiOB7IgUcxGiRbOmHVgfMs5KmpGtplgf+rb/Qa9BsvGLLwKyDTtfyZ5nHGu ooWnipXRd+e26b3dnG7gOVBJ0TJjfhYmocjoTNsgdN/PsuaYaL1VR2cV70h9saKCp33f /nStFmLM3kO31lsWTBetOOkcU2/fYjxJGnsRJXy9YcNnlVuu8ZM3DLJKcL9pD+SjojTM tTCjt9EtX9m1kyO0D3XLDp8Cq5B4ftU79o4S2JadIf467Ig8DxyqfIyV+Uxh3BRVld/k KP2oCbYszyFpIE/wC8p7XmkSc63ahD2VgqHH8nBKB8MzWK7IYSyRA8WJqlv52x6qSNm6 PR9Q== 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:references :mime-version:content-disposition:in-reply-to; bh=2N6CS2fvX/5meXayqhTZX1D1m4xxvqwL2vqiRfInLNY=; b=lswRtDH7oEWhHu4kujod1BofFqdvSMhpdTMXyT1FwqVpUcJLfl/FoiMYzPrmcVEKRt 7NAmnAt+m+22RzTL1A1e1tO0QKtsXz5S3FMq5dGF36chVV2Jgvsg9JrLq/FOcw+/aROr ypbmMPSZ0BA6R4pBak2oK57yIQO2YRbowjSE8gRl+sPhHomm6qQ4oUm3uagNSZzvVzNy jkNqkamjixlB01J1l8HSMuh9cQQcPfxod+seAnkA/Y9nDKgtaUGBJ4+t23zvH6ya+lbP VMQZTwTYK7zKQE4OkL0Cu7U6d6poF+7lrlxFTb92WJf6eyRd0iP/Ss63AVWWWOWdAP4G 1VwA== X-Gm-Message-State: AKwxytfONoTAnbh1toboBd/7Ri0iuoSEuRDcUU5lwUY6ZFlO+ksLP12/ nh8qykGX41WB8gZeeUarupbdXW94 X-Google-Smtp-Source: AH8x225kRU/SOPWmuBlb541P7stTXBDR5T+RJ6+hze3CAMXPBTXO2rM6NhCYYPeFxRi5dWmoy+plSQ== X-Received: by 10.223.152.20 with SMTP id v20mr27023844wrb.222.1517838299463; Mon, 05 Feb 2018 05:44:59 -0800 (PST) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id 42sm15565658wrw.15.2018.02.05.05.44.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Feb 2018 05:44:58 -0800 (PST) Date: Mon, 5 Feb 2018 14:44:46 +0100 From: Adrien Mazarguil To: Marcelo Ricardo Leitner Cc: "Van Haaren, Harry" , Thomas Monjalon , "dev@dpdk.org" , Shahaf Shuler , Nelio Laranjeiro Message-ID: <20180205134446.GG4256@6wind.com> References: <20180202144736.8239-1-adrien.mazarguil@6wind.com> <20180202164050.13017-1-adrien.mazarguil@6wind.com> <20180202164050.13017-4-adrien.mazarguil@6wind.com> <6047554.pbob4v6vxF@xps> <20180205112402.GE4256@6wind.com> <20180205121339.GB27676@localhost.localdomain> <20180205125806.GE27676@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180205125806.GE27676@localhost.localdomain> Subject: Re: [dpdk-dev] [PATCH v2 3/4] net/mlx: version rdma-core glue libraries 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: Mon, 05 Feb 2018 13:44:59 -0000 On Mon, Feb 05, 2018 at 10:58:06AM -0200, Marcelo Ricardo Leitner wrote: > On Mon, Feb 05, 2018 at 12:24:23PM +0000, Van Haaren, Harry wrote: > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Marcelo Ricardo Leitner > > > Sent: Monday, February 5, 2018 12:14 PM > > > To: Adrien Mazarguil > > > Cc: Thomas Monjalon ; dev@dpdk.org; Shahaf Shuler > > > ; Nelio Laranjeiro > > > Subject: Re: [dpdk-dev] [PATCH v2 3/4] net/mlx: version rdma-core glue > > > libraries > > > > > > On Mon, Feb 05, 2018 at 12:24:02PM +0100, Adrien Mazarguil wrote: > > > > On Sun, Feb 04, 2018 at 03:29:38PM +0100, Thomas Monjalon wrote: > > > > > 02/02/2018 17:46, Adrien Mazarguil: > > > > > > --- a/drivers/net/mlx4/Makefile > > > > > > +++ b/drivers/net/mlx4/Makefile > > > > > > @@ -33,7 +33,9 @@ include $(RTE_SDK)/mk/rte.vars.mk > > > > > > > > > > > > # Library name. > > > > > > LIB = librte_pmd_mlx4.a > > > > > > -LIB_GLUE = librte_pmd_mlx4_glue.so > > > > > > +LIB_GLUE = $(LIB_GLUE_BASE).$(LIB_GLUE_VERSION) > > > > > > +LIB_GLUE_BASE = librte_pmd_mlx4_glue.so > > > > > > +LIB_GLUE_VERSION = 18.02.1 > > > > > > > > > > You should use the version number of the release, i.e. 18.02.0 > > > > > Ideally, you should retrieve it from rte_version.h. > > > > > > > > Keep in mind this only needs to be updated when the glue API gets > > > modified, > > > > and this "18.02.1" string may remain unmodified for subsequent DPDK > > > > releases, probably as long as the PMD doesn't use any new rdma-core calls. > > > > > > > > We've already backported this patch to 17.02 and 17.11, both requiring > > > > different sets of Verbs calls and thus a different version, hence the > > > added > > > > "18.02" as a starting point. The last digit may have to be modified > > > possibly > > > > several times between official DPDK releases while work is being done on > > > the > > > > PMD (i.e. per commit). > > > > > > > > In short it's not meant to follow DPDK's public versioning scheme. If you > > > > really think it should, doing so will make things more complex in the > > > > Makefile, which will have to parse rte_version.h. What's your opinion? > > > > > > What about appending date +%s output to it? It would be stricter and > > > automated. > > > > Adding current timestamp or date into a build breaks reproducibility of builds, so is > > generally not recommended. > > Then the sha1sum of mlx4_glue.h. > With this the size check I mentioned on the other patch would become > redundant and unnecessary. Using a strong hash algorithm to version a library/symbol, while possible, seems a bit overkill and results in ugliness: librte_pmd_mlx4.so.c4ca4eaf2fe975ead83453458f4f56db49e724f3 Using a weak one like CRC32 for a shorter name poses a risk of collision. Moreover the next time someone decides to update all version notices or modify a comment will impact that hash. We'd need to isolate the symbol definition itself, ignore parameter names in function prototypes and only then we may get a somewhat meaningful hash describing a given ABI. Given the added complexity, is there really a problem with simple version numbers we increment every time something gets modified? (Note this is already how our .map files work, they're not generated automatically) How about keeping things as is? -- Adrien Mazarguil 6WIND