From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 15DD0A00C4; Fri, 29 Jul 2022 15:22:59 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E0B044069C; Fri, 29 Jul 2022 15:22:58 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 5A9B640151 for ; Fri, 29 Jul 2022 15:22:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1659100976; 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: in-reply-to:in-reply-to:references:references; bh=8I/Gj4gZxrn/pqYem0y4imT27T0C8NiVDyOtYwKUsqs=; b=BKjxcL+kK0wQWSl9t4kWAkH7yMynaiajZXJlHjywNsw+KUXf7lgtY+ElDWmxq/BhtzegMl ch6/jMUbUv2C5VwawYri+2KsRm37Jx51pCed4B9o1PGOKMrS3eh9JmHFsG+Z0fVToaq7yW 6+JZT79QoAg9J5wUaHY30AMB5+YpvCU= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-354-cK4fbtx1OpKN3Vq4lsZPYQ-1; Fri, 29 Jul 2022 09:22:55 -0400 X-MC-Unique: cK4fbtx1OpKN3Vq4lsZPYQ-1 Received: by mail-lf1-f71.google.com with SMTP id z1-20020a0565120c0100b0048ab2910b13so1647710lfu.23 for ; Fri, 29 Jul 2022 06:22:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8I/Gj4gZxrn/pqYem0y4imT27T0C8NiVDyOtYwKUsqs=; b=iCvXXbTrmE+FriXBj1xOme6oxrBWksthuNIalbaxibejKxh+1hChtvwi3D2WM/IgGb bfJcD/4qLHEHD1pJoIN8OK4A3lcUnikspk/9AIYLALQ6s9S8u4Z942HuBUfpHrasIAgV XIVb/zx7DVB/XjBoMl8ci3lbSzWNPvJ+uVgD8gNl7WncshxXNrEQQBRqw74GcYqSIpYr xmnW8k1dHwWXY7GjKqN4mhP7TEw6hHgpRDnXJ6liiBFEsFJ2DpVQW2taJ1tt+SPqY7NB LqXJ7QYTccKJeezqYxcwy1DtP3DbtLth7iBZotALdH4Fp4xrnuA+POHUqluQ1XDr2fby 8jEA== X-Gm-Message-State: AJIora9DZeiQ5KsofZ5ouEhr6s8AorNt0zC/mjWWjASNbttCI2zmCFIT emg3hpzKp68ozwf6T5w3eHEjs7rxLOibN3/+jrcYnDedgqbhnK4wBc2JfRjk5UJmpM7qTlelyDw wOIg6Swel3jemNRjLl/c= X-Received: by 2002:a19:7917:0:b0:48a:d336:9697 with SMTP id u23-20020a197917000000b0048ad3369697mr1316200lfc.217.1659100974236; Fri, 29 Jul 2022 06:22:54 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sN3nWYVHxc0K7qUuKUb6eUAtVDYTR2aNE6tBK6Ci8DyqeJI9AW/99zqmvPn6dOwOmHkSY+KtQuU1QOqiTJDWw= X-Received: by 2002:a19:7917:0:b0:48a:d336:9697 with SMTP id u23-20020a197917000000b0048ad3369697mr1316180lfc.217.1659100973657; Fri, 29 Jul 2022 06:22:53 -0700 (PDT) MIME-Version: 1.0 References: <20220628144643.1213026-1-david.marchand@redhat.com> <20220728152640.547725-1-david.marchand@redhat.com> <20220728152640.547725-9-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Fri, 29 Jul 2022 15:22:42 +0200 Message-ID: Subject: Re: [RFC v3 08/26] dev: move unrelated macros from header To: Bruce Richardson Cc: dev , Fan Zhang , Ashish Gupta , Qiming Yang , Wenjun Wu , Shijith Thotton , Srisivasubramanian Srinivasan , Chengwen Feng , Kevin Laatz , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , Olivier Matz , Ori Kam , Akhil Goyal , Maxime Coquelin , Chenbo Xia Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, Jul 29, 2022 at 11:59 AM Bruce Richardson wrote: > > > Personally, I really don't like these macros at all. I think having the > > > check explicitly in the code would be far more readable, and would only be > > > one line of code longer than the macro call. Is there some private header > > > file we could move these to instead of rte_common.h so we can drop their > > > use in future if we decide to? > > > > I don't like them either. > > Not sure where to put them though... > > > > My "grep-all" shows no user in the projects consuming DPDK I track. > > We could mark those macros deprecated, fix our code and drop them later. > > > +1 to that. > Can they be marked as deprecated as part of the move perhaps (assuming we > get agreement to kill them?) Yes. I'll wait for others to chime in, which means this will wait for after my days off :-). -- David Marchand