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 938F1A04C3; Tue, 26 Nov 2019 10:50:43 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 05F7C2C60; Tue, 26 Nov 2019 10:50:43 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id 2124F2B96 for ; Tue, 26 Nov 2019 10:50:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574761841; 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=M28A05SsUvlRgxDssdxcvH43kZabUqco9zT/uLvbaEqcDfkg/0HpZVbxXMnSgr0UAjFrxa KXNJK60FFBGbpi+Mpf2t7wNURqfXVOPefqFUNZ7DauIb0r0RExXXnhZc+MyxCQ614vFNtD v893NgukAS+SLM1Cq6Rim9t5D8eNUIQ= Received: from mail-vk1-f198.google.com (mail-vk1-f198.google.com [209.85.221.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-217-vQWyfEa0OwWYYTjnL4f7Zg-1; Tue, 26 Nov 2019 04:50:38 -0500 Received: by mail-vk1-f198.google.com with SMTP id n6so8717034vke.22 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=KF4ClU/ihVmZWmemx3TLo8t3hAnR/pyqKpyCyzLSvGq0mjSLfz9cC2K5V4Bc6twM0D yaof6yros70qbz8tNwX8wRXcvG3/nB3Ra24/xuu4ABnFEodpCAg5ehzjAXyF9A3zDC9L XqSpmZvyaFY7ahEzxK2ooFFD5lL5Dyt4KwciNV4dXxOfdsra5eMJjPpoh1EnX9Nu3146 HjMm2TbPcFOilGmiDQzT+ld1Ne2/mJEKhkX30NC3tZ7OOv+HGCRp8f+KVMOKLFZlxBpA LhcU8uHFNBTIrONX2aE1i/+HmmBa4mYwbU2MnPRS+1KZV86E434La0lV3UnynP2hse71 dgmA== X-Gm-Message-State: APjAAAWEVb8siCN0/nXnzlQcoSMYbKW1RWxisxufBNvUWI6nSo7kizax NQxkWanqNeB7o17IR6Wf9aWRXWQWV4xc3rkpX4bL06XIqpxLF7z6/u5yTALzJI/ADVHsOVTfu1p 0KL7ZUUaBp4IL3GdGFhE= X-Received: by 2002:a67:bd05:: with SMTP id y5mr22118461vsq.180.1574761837872; 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: vQWyfEa0OwWYYTjnL4f7Zg-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [RFC PATCH] mark experimental variables 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" 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