From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1F588A04C3 for ; Tue, 26 Nov 2019 10:50:42 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CFDAACF3; Tue, 26 Nov 2019 10:50:41 +0100 (CET) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id 17AE8CF3 for ; Tue, 26 Nov 2019 10:50:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574761840; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ehGCA+ld1SB1M6wt2IVFwmgRDHPusNHUiqAdK4b05Pw=; b=NJYfAX8gfQLbwFBInT/aUOpLHOuUQYYdVgD0JBSNAwna4gnNume2EChVVNMJSZpVYrkA8P gsJ2A+EOTjALrY1iMiTHpftkVBg0coEj2EMHudAprGeJKUCAcw+YgAff77R7cjHYy4JJ+P JF+C/vsQXQlqSLBcIJqAxHNEQi89/uA= Received: from mail-vk1-f199.google.com (mail-vk1-f199.google.com [209.85.221.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-217-k-TAfE11PfKSyxnHrDPwFw-1; Tue, 26 Nov 2019 04:50:38 -0500 Received: by mail-vk1-f199.google.com with SMTP id y75so8747247vkc.0 for ; Tue, 26 Nov 2019 01:50:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oyqx8Ye/pDabMzU09zdG6AaNBRnYY2j2p+rr2gDeE5k=; b=kv+r51xIF6UWmNsHW0t9UGaUEOa1mpsauMx6ZELov7UpHdpSddgEWxGMd5ssxUwvq5 2odmk5kufmrIl7tNg0EsBYbbwgVmSU1mmTqwpU/De8+oKTQELUpta23do+pyWKSKe9KZ 126PF2T7nacASnNN+b0ehy3JM5DI+4i+bBdef9rdNe5LsfAUReI+o7Nty06Z7r3VEvzU JTAixspkv9YHVVOsdyrApQFi+VyEEF4YBQIopJhZZa2ql0COGdfmT5OyTgKrh8jbWuXc d1H/XKRkE3Ft7ZTxlXwASPsqW7AZ8Kn0DUN/pLWYSNLvBwmGOfs3yNgsjxkftiEPF+dL IttQ== X-Gm-Message-State: APjAAAWfaqrwcdGlH1+pYqsEECJmYtxQx9MYJiGpCmuQmcMSt3MrJzjG e1yOSDhY1RFOLOCckBrABndb8OmCiUK2+uVGJ5doIqF1NwroVBv+0I0PTWiSRwRa8l4/bI3B90L ctftESITV5ZcBmz7wZOH2cdo= X-Received: by 2002:a67:bd05:: with SMTP id y5mr22118460vsq.180.1574761837871; Tue, 26 Nov 2019 01:50:37 -0800 (PST) X-Google-Smtp-Source: APXvYqylsNhpdi9vOEtJLN4g5x/qNLZg5qnVsS9FwPIYhT/5+0w4z1BWXz+FTYs4S84/kLW0SU9meIKw3s3cxxNqou8= X-Received: by 2002:a67:bd05:: with SMTP id y5mr22118442vsq.180.1574761837453; Tue, 26 Nov 2019 01:50:37 -0800 (PST) MIME-Version: 1.0 References: <20191125161314.18804-1-david.marchand@redhat.com> <23c3c0ff-6cf1-3aca-50b8-a89037afdcac@ashroe.eu> In-Reply-To: <23c3c0ff-6cf1-3aca-50b8-a89037afdcac@ashroe.eu> From: David Marchand Date: Tue, 26 Nov 2019 10:50:26 +0100 Message-ID: To: Ray Kinsella Cc: Neil Horman , dev , Thomas Monjalon , Andrew Rybchenko , dpdk stable , John McNamara , Marko Kovacevic , Qiming Yang , Wenzhuo Lu , Declan Doherty , Adrien Mazarguil , Ferruh Yigit , Cristian Dumitrescu X-MC-Unique: k-TAfE11PfKSyxnHrDPwFw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-stable] [RFC PATCH] mark experimental variables X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On Tue, Nov 26, 2019 at 10:26 AM Ray Kinsella wrote: > > > My 2c is that it feels a little unweildy to have to annotate, every varia= ble declaration. > and also extern reference with __rte_experimental_var. > > Is there any easier way? We use this framework so that the users are aware they are relying on experimental API that can change overnight. It would not happen if we could hide all of this behind accessors. But here we reference them through macros / inlines with performance in min= d. This performance impact needs to be confirmed as a real requirement. I caught some oddity like the librte_port stuff (with no in-tree users, but different topic). > > @@ -90,11 +90,15 @@ check_experimental_tags() { # > > "headers ("current_file")"; > > ret =3D 1; > > } > > - if ($1 !=3D "+__rte_experimental" || $2 !=3D "") { > > - print "__rte_experimental must appear alone on th= e line" \ > > - " immediately preceding the return type o= f a function." > > - ret =3D 1; > > + > > + if (NF =3D=3D 1 && ($1 =3D=3D "+__rte_experimental" || > > + $1 =3D=3D "+__rte_experimental_var")) { > > + next; > > } > > + print "__rte_experimental or __rte_experimental_var must = " \ > > + "appear alone on the line immediately preceding t= he " \ > > + "return type of a function."; > > or variable? Yes. > > @@ -300,9 +300,10 @@ Note that marking an API as experimental is a mult= i step process. > > To mark an API as experimental, the symbols which are desired to be ex= ported > > must be placed in an EXPERIMENTAL version block in the corresponding l= ibraries' > > version map script. > > -Secondly, the corresponding prototypes of those exported functions (in= the > > -development header files), must be marked with the ``__rte_experimenta= l`` tag > > -(see ``rte_compat.h``). > > +Secondly, the corresponding prototypes of those exported functions (re= sp. > > +variables) must be marked with the ``__rte_experimental`` (resp. > > +``__rte_experimental_var``) tag in the development header files (see > > +``rte_compat.h``). > > Suggest simplifying as follows (remove the resp.). > > Secondly, the corresponding prototypes of those exported functions (or > variables) must be marked with the ``__rte_experimental`` (or > ``__rte_experimental_var``) tag in the development header files (see > ``rte_compat.h``). "or" sounds better. --=20 David Marchand