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 912DE459CB; Wed, 18 Sep 2024 13:15:42 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3830142D28; Wed, 18 Sep 2024 13:15:42 +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 58F98402BA for ; Wed, 18 Sep 2024 13:15:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1726658139; 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=c5nQXGuwqWYhGmuNPXWx0eaSzwu6m1TvCLazju7JPrA=; b=XjouoHDens3f7QriACU1PpZFxDOPv9hGYFk4ukJ5VTgIgr7LJ0K9t1Gh5M14jccIlMLtMu 2bJTQN3eyVlabp2Xw9NoDQvunB/pWngwlUPwlMjy6//3ZK0SMIP9heYOl51nlMqGsfAy9r 5au5Ypv/EFmrEg/ihRB4H3/uVigXrXs= Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-458-QFp6F28HM_OoNQLmwSHdqw-1; Wed, 18 Sep 2024 07:15:38 -0400 X-MC-Unique: QFp6F28HM_OoNQLmwSHdqw-1 Received: by mail-lj1-f199.google.com with SMTP id 38308e7fff4ca-2f761cfa5c8so49068551fa.1 for ; Wed, 18 Sep 2024 04:15:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726658137; x=1727262937; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=c5nQXGuwqWYhGmuNPXWx0eaSzwu6m1TvCLazju7JPrA=; b=MTgXVrMhHZ/HKwBbCp4lEqSGa2GN3Y4tcBH2FhtqPNWKH29q+kWmsgrnue+RQXP8WB v2qQ70pioZvoEmYNk1EQ2YBgu98OAnPdwkQ5NCXzlWKfB46OWznCN+mm9hQWfQZdn50B qwp+PTfARvzTNUEf4d5h/IHdVmbI/iOP530QAl4zC3NQ8YJe0Ybpc9Hd/F1mbTfIBgGT 8F+J+mryaXQK9O41ToqOjBqjLJAEv2NyrUC3WgUf7S3B9ZXEtKdVMUtgzvDZniIxJHFm NeElPHsHTdOkmtFAIipyHaV/GnEH76WTyPEcVpLz3LljhCYCP+UAJj2YLXdmIvR962z6 4Hmw== X-Forwarded-Encrypted: i=1; AJvYcCVGu22Ah1jgyGQE8i32i4RWJEw1O0Q+r25bjlpwYTyA0xW6Y6vNtmrWpm7PXPfhMJSm6yY=@dpdk.org X-Gm-Message-State: AOJu0YyDS4hZ6ZmGMSrPnzoR2KPxpYgbG2nYwQ9vXSMpLYmd1G8Nmixv WgHyF5MZKyxzuYKnH5msRX5HPn6qR+DqosLrbtrKOmQr797HYsJ2WugEP2Ah+PccWFB+j74qOt2 c/iJ/xJAycfw+sRnut+HUXUuS1iWSt+nqVabbay7Ajg0xvBFKVTicUu3OteFI5YirYhwXApkmFx gRP1jJUi7ZB2rrDIg= X-Received: by 2002:a2e:b8c4:0:b0:2ec:1810:e50a with SMTP id 38308e7fff4ca-2f787f449e2mr122601381fa.32.1726658136983; Wed, 18 Sep 2024 04:15:36 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEdvXTPYD35OVkHeg32VZP7cjcOa6PxT5Bj3WhuxpSRoJoB6JR/eyo8eh94Hh3ZeMe96KvKyzzmJJhoMTVTFZE= X-Received: by 2002:a2e:b8c4:0:b0:2ec:1810:e50a with SMTP id 38308e7fff4ca-2f787f449e2mr122601121fa.32.1726658136435; Wed, 18 Sep 2024 04:15:36 -0700 (PDT) MIME-Version: 1.0 References: <20240910062051.699096-2-mattias.ronnblom@ericsson.com> <20240910083139.699291-1-mattias.ronnblom@ericsson.com> <20240910083139.699291-2-mattias.ronnblom@ericsson.com> <8a06d4ce-0058-4a16-b89e-4a8b2bed77f3@lysator.liu.se> In-Reply-To: <8a06d4ce-0058-4a16-b89e-4a8b2bed77f3@lysator.liu.se> From: David Marchand Date: Wed, 18 Sep 2024 13:15:24 +0200 Message-ID: Subject: Re: [PATCH v6 1/6] dpdk: do not force C linkage on include file dependencies To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , Bruce Richardson , Tyler Retzlaff Cc: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , dev@dpdk.org, Heng Wang , Stephen Hemminger , =?UTF-8?Q?Morten_Br=C3=B8rup?= , Jack Bond-Preston , Chengwen Feng X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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 Tue, Sep 17, 2024 at 11:30=E2=80=AFAM Mattias R=C3=B6nnblom wrote: > > On 2024-09-16 14:05, David Marchand wrote: > > Hello, > > > > On Tue, Sep 10, 2024 at 10:41=E2=80=AFAM Mattias R=C3=B6nnblom > > wrote: > >> diff --git a/lib/acl/rte_acl_osdep.h b/lib/acl/rte_acl_osdep.h > >> index 3c1dc402ca..e4c7d07c69 100644 > >> --- a/lib/acl/rte_acl_osdep.h > >> +++ b/lib/acl/rte_acl_osdep.h > >> @@ -5,10 +5,6 @@ > >> #ifndef _RTE_ACL_OSDEP_H_ > >> #define _RTE_ACL_OSDEP_H_ > >> > >> -#ifdef __cplusplus > >> -extern "C" { > >> -#endif > >> - > >> /** > >> * @file > >> * > >> @@ -49,6 +45,10 @@ extern "C" { > >> #include > >> #include > >> > >> +#ifdef __cplusplus > >> +extern "C" { > >> +#endif > >> + > >> #ifdef __cplusplus > >> } > >> #endif > > > > This part is a NOOP, so we can just drop it. > > > > I did try to drop such NOOPs, but then something called > sanitycheckcpp.exe failed the build because it required 'extern "C"' in > those header files. > > Isn't that check superfluous? A missing 'extern "C"' would be detected > at a later stage, when the dummy C++ programs are compiled against the > public header files. > > If we agree santifycheckcpp.exe should be fixed, is that a separate > patch or need it be a part of this patch set? This check was added with 1ee492bdc4ff ("buildtools/chkincs: check missing C++ guards"). The check is too naive, and I am not sure we can actually make a better one= ... I would remove this check, if no better option. > >> diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/ge= neric/rte_atomic.h > >> index f859707744..0a4f3f8528 100644 > >> --- a/lib/eal/include/generic/rte_atomic.h > >> +++ b/lib/eal/include/generic/rte_atomic.h > >> @@ -17,6 +17,10 @@ > >> #include > >> #include > >> > >> +#ifdef __cplusplus > >> +extern "C" { > >> +#endif > >> + > >> #ifdef __DOXYGEN__ > >> > >> /** @name Memory Barrier > >> @@ -1156,4 +1160,8 @@ rte_atomic128_cmp_exchange(rte_int128_t *dst, > >> > >> #endif /* __DOXYGEN__ */ > >> > >> +#ifdef __cplusplus > >> +} > >> +#endif > >> + > > > > I would move under #ifdef DOXYGEN. > > > > Why? The pattern now is "almost always directly after the #includes". > That is better than before, but not ideal. C linkage should only be > covering functions and global variables declared, I think. I hear you about how the marking was done but it already has some manual edits (seeing how some fixes were needed). --=20 David Marchand