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 732B1A034C; Fri, 25 Feb 2022 00:03:08 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0892440688; Fri, 25 Feb 2022 00:03:08 +0100 (CET) Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) by mails.dpdk.org (Postfix) with ESMTP id 1038740141 for ; Fri, 25 Feb 2022 00:03:06 +0100 (CET) Received: by mail-pg1-f170.google.com with SMTP id o23so2987517pgk.13 for ; Thu, 24 Feb 2022 15:03:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=YGr7OjQXO/pSJm+OQGCjt9z2/Cg0pu5UfqpyarxNs8E=; b=MwlPQKqZlFrOs+fBZQ5+lqyneU74Kn+u4fTdThg3I8B7KiMiB6YNpL2zqNn39V2LqV 9igHH6Bcq0H51A+ZFy32FbEWZyeaUA7b+fwguKrc5dgY5UtHUlqb5OjF8rRWN9T1J4KO v3dmm+Dp1zWoIzPso/SjFukwCei5jKP3YmR3VbA4Z0YuaGFSH0Ey9oGSjrzNg5CfDx5X sLeLmYgldUtLK2Wy/h8ebPV/MOBy6KSRHMOAcKCSnrtv2hz8zusTuOpFhstPWCu8JSsb tKpdjvvEYXh1u9BewV7unntXR4YfdJpqNM2AefbTgkS430PSGIF6AA3eFk0J88sor7WC 3DvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=YGr7OjQXO/pSJm+OQGCjt9z2/Cg0pu5UfqpyarxNs8E=; b=nu/cELgxvfiO5g9x5t2pE3u6vUjKZojwP6bS5wDon79kgn4hS5k4jm7iNcZTl8ylkr k8cuBx35HalkZLXD1cCig90I51Mppuk6cH96i8KV2f2OlJ3/MN8nwuxOvFqZV+H9byA2 ftuGcjqTsptGDSGXmm5W2fPkNEqnbZVRi/eY0ojFgKNPRoRoaBA5sQiIFjbXZm/Cdm/X JgRsldkhZbGNXgYhgVyiFsdUJVjiGZ19qe4yOmfFS54fZKZXbHB2p+oZVqMxmPAy3oSF bZGjTcrzc0ODQHTR4+ZcfxGlearp1QsQDfyOmir/UaFS75UHL+/UF9Cvp3ZtYQgS5MBo 423Q== X-Gm-Message-State: AOAM530a3p/M8jEjz7qelHHczAze0plvdwNPxLj2O8TsUdOSnew2PxNB GCWnEx2imfgbSG9v/JwP4rI0ZQ== X-Google-Smtp-Source: ABdhPJy/1RuvCAw5EqQqmfNyanSW8QpOWbkt0Hd49xZETVCawOVL2092bghJ0dDLlQ62nduZK9SbMg== X-Received: by 2002:a62:5ac6:0:b0:4df:34dc:d6c5 with SMTP id o189-20020a625ac6000000b004df34dcd6c5mr5009587pfb.9.1645743785001; Thu, 24 Feb 2022 15:03:05 -0800 (PST) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id q13-20020aa7960d000000b004f13804c100sm494579pfg.165.2022.02.24.15.03.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Feb 2022 15:03:04 -0800 (PST) Date: Thu, 24 Feb 2022 15:03:01 -0800 From: Stephen Hemminger To: Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: "Tyler Retzlaff" , "Bruce Richardson" , Subject: Re: [RFC 0/2] Eliminate zero length arrays in DPDK Message-ID: <20220224150301.04873923@hermes.local> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D86EF2@smartserver.smartshare.dk> References: <20220215230058.64760-1-stephen@networkplumber.org> <98CBD80474FA8B44BF855DF32C47DC35D86EB0@smartserver.smartshare.dk> <20220217074139.GA1815@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35D86EF2@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 Thu, 24 Feb 2022 22:51:31 +0100 Morten Br=C3=B8rup wrote: > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > Sent: Thursday, 17 February 2022 08.42 > >=20 > > On Wed, Feb 16, 2022 at 10:10:01AM +0000, Bruce Richardson wrote: =20 > > > On Wed, Feb 16, 2022 at 11:05:09AM +0100, Morten Br=C3=B8rup wrote: = =20 > > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > > > > Sent: Wednesday, 16 February 2022 10.33 > > > > > > > > > > On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger =20 > > wrote: =20 > > > > > > Yet another case of applying Linux kernel best practices > > > > > > to DPDK. Flexible arrays are supported by Clang, GCC and > > > > > > Microsoft compilers (part of C99). > > > > > > =20 > > > > > Do we need to start explicitly stating that DPDK uses C99 =20 > > features, and =20 > > > > > adding -std=3Dc99 to our build flags? Are we also requiring that > > > > > applications > > > > > are compiled with c99 features to use this (I would hope that =20 > > they are, =20 > > > > > but > > > > > I'm not sure we can mandate it). =20 > > > > > > > > No to -std=3Dc99. It's >=3D C99 for applications; we should not pre= vent =20 > > them from using a newer C standard. =20 > > > > > > Yes. For build flags, I was referring only to having it in the cflags= =20 > > for the =20 > > > build of DPDK itself, not for apps. We definitely need to minimise =20 > > the =20 > > > build flags we expose to apps. > > > =20 > > > > > > > > Adding a note about the C standard version to the DPDK requirements > > > > documentation would be very nice. It only mentions a certain =20 > > compiler =20 > > > > version required. But I think that documenting the detailed build = =20 > > and =20 > > > > runtime requirements (and why they are that way) is another task. > > > > =20 > > > Sure, we should do that. I am just wanting to be sure that if we =20 > > specify a =20 > > > minimum of C99, we won't get complaints back from those with legacy > > > codebasees which only support C89/C90. I am therefore wondering if we= =20 > > need =20 > > > to have our public headers C90-compliant? =20 > >=20 > > this seems to be the real question. what "minimum" C standard should be > > documented as required to consume dpdk. we can obviously use any > > standard > > we wish to build/provide binaries. similarly we ought to document a > > minimum C++ standard for consumption. > >=20 > > i would advocate for C99 however before setting that in stone it is > > fair > > to ask if there are any consumers using < C99. > >=20 > > we may also want to consider that the minimum required may differ > > depending on the platform/port. though most differences in public > > interface > > i would hope could be trivially abstracted though. > >=20 > > ty =20 >=20 > Just read that the Linux kernel is moving towards C11, or at minimum C99,= for version 5.18: > https://lwn.net/SubscriberLink/885941/01fdc39df2ecc25f/ >=20 > Let's be bold and push for the same for DPDK! :-) Would be good, but still getting held back by legacy distros (RHEL) and other compiler environments ICC, etc.