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 18D09A0543; Mon, 13 Jun 2022 14:26:30 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 07C4440150; Mon, 13 Jun 2022 14:26:30 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 527BD400EF for ; Mon, 13 Jun 2022 14:26:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655123188; 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=6vijz/Wo6VMaVB/GkAzGq/xusssOyS0Nh0hVfBnIFo4=; b=KPiEXlx+KkLzqi097DqBtQrkqe3ceBejwg5dv2OrMCbSQU0osB5dO6/WOyLxUDDRatl1j9 mfIVrserLn0pscdvIqih+bz2/7ESrkUwF81MXj44DOiDMVibwRxcvlGUnHw8YZoGsA+tE3 W9IyYZOxHXe/MWudxiVDZzcCuAnnCjk= Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-373-KjWowyucP2yoBKpTy76h_A-1; Mon, 13 Jun 2022 08:26:27 -0400 X-MC-Unique: KjWowyucP2yoBKpTy76h_A-1 Received: by mail-lj1-f198.google.com with SMTP id a17-20020a2eb171000000b002556cda407aso617262ljm.9 for ; Mon, 13 Jun 2022 05:26:27 -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=6vijz/Wo6VMaVB/GkAzGq/xusssOyS0Nh0hVfBnIFo4=; b=5PqSlki5DKAedX3AbSdojh70hAJ6la74HGgiDF4aOiCrBgAATxpBvX3Q4u1OM6NBRp E/9nm31LcZ9ysW4wC4ByQF0YDE65IKI+Bb/HHWgKEGpwqLO+b+Dq7M5IP0PAuFYhZOLi ImFvSVmrR8jDyoR+hufgh0ILLlEG09q10OJTCa1Z+DLy52X4L1UVzez1ud/7xbHeH9LE MnWTEWVlPezsbS6FaD/afu8gQXK6di6xRenWY2hyqSQWQy6pWIQBvzKdxHVdNEyKRPMr V7d+GVHmenwMjeU6bkwD9UfzXtg0vLNyZrS1N5xuV+eSPksBGZmGG6elCOYCC2sSVhLp bbSw== X-Gm-Message-State: AOAM53280b7FT2YeNTlt/Q6EI55EKDP/wxSBl3fp4dQEdpMkv5Hv+6dc cG5z8V3YcmMbUzGCfiaRP74UfBolzDv6yUni3vseJsaaJuZLO0JKmG9KjOtquKBmChA7B0Onbpk 9ihxf9fSRsPUF7caqm3g= X-Received: by 2002:a05:651c:a04:b0:255:bf2e:72b9 with SMTP id k4-20020a05651c0a0400b00255bf2e72b9mr14925713ljq.333.1655123186100; Mon, 13 Jun 2022 05:26:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzpRz1Xq1wtiisuTaeYnM2p5TrrIaAQU5lXOh6p8vqWx8veQD0LB5EKaLkXBAhtPgrKu+ImT5Y/8N6Oz+7ljs4= X-Received: by 2002:a05:651c:a04:b0:255:bf2e:72b9 with SMTP id k4-20020a05651c0a0400b00255bf2e72b9mr14925699ljq.333.1655123185875; Mon, 13 Jun 2022 05:26:25 -0700 (PDT) MIME-Version: 1.0 References: <20211216111430.699717-1-bruce.richardson@intel.com> In-Reply-To: From: David Marchand Date: Mon, 13 Jun 2022 14:26:14 +0200 Message-ID: Subject: Re: [PATCH] config: remove explicit undef of unset values To: Bruce Richardson Cc: dev , "Dong, JunX" , =?UTF-8?Q?Morten_Br=C3=B8rup?= , Thomas Monjalon 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 Mon, Jun 13, 2022 at 11:54 AM Bruce Richardson wrote: > On Thu, Dec 16, 2021 at 11:14:30AM +0000, Bruce Richardson wrote: > > Rather than explicitly clearing any setting of undefined values in our > > rte_config.h file, it's better to instead just add a comment that the > > value is not set. Using a comment allows the user to set the value using > > CFLAGS or similar mechanism without the config file clearing the value > > again. > > > > The text used " is not set" is modelled after the kernel approach > > of doing the same thing. > > > > Signed-off-by: Bruce Richardson > > --- > > > > Although DPDK coding convention forbids use of "//" for comments, using > > regular C comment style makes the config settings less clear, as they can > > be confused with regular comments in the file. Using "//" makes them stand > > out better, so I prefer it. However, if others feel strongly, they can be > > changed to standard. > > > > Note: this is a resubmission of patch [1] which was part of a rejected > > series. However, the reasons for rejection - values in config being out > > of sync with those used for building apps - are less relevant for > > many, if not all, of these setting, so I believe the benefits for > > testing outweigh the potential downsides. If any setting is likely > > problematic, I can keep the explicit undef for that case in a new patch > > version. > > > > [1] http://patches.dpdk.org/project/dpdk/patch/20200903144942.671870-2-bruce.richardson@intel.com/ > > --- > > Ping for review or feedback for this patch. I'd like to see it move forward > into a DPDK release if possible. I'd like a check like (below), to avoid new additions: diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh index 34a2e43845..8dae47165e 100755 --- a/devtools/checkpatches.sh +++ b/devtools/checkpatches.sh @@ -158,6 +158,14 @@ check_forbidden_additions() { # -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \ "$1" || res=1 + # '// XXX is not set' must be preferred over '#undef XXX' + awk -v FOLDERS='config/rte_config.h' \ + -v EXPRESSIONS='#undef' \ + -v RET_ON_FAIL=1 \ + -v MESSAGE='Using "#undef XXX", prefer "// XXX is not set"' \ + -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \ + "$1" || res=1 + return $res } Otherwise, the change lgtm. -- David Marchand