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 515FCA054F; Tue, 2 Mar 2021 01:22:56 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D628C4014E; Tue, 2 Mar 2021 01:22:55 +0100 (CET) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by mails.dpdk.org (Postfix) with ESMTP id 7CD1E40142 for ; Tue, 2 Mar 2021 01:22:54 +0100 (CET) Received: by mail-lf1-f47.google.com with SMTP id k9so8577135lfo.12 for ; Mon, 01 Mar 2021 16:22:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=FscF0IDiMjkYGyFEyrGjTC5aofwZiC6ayHh3t28wK+4=; b=AYvXlLfXQoelJZc2PzQVhH+hrbsSljhfJKz23Q3jC2dN8mY2q5gWBcnalDMS9hM+8a YaeIruIsTgCz6W9AT9Y38YIy7R9lfVZznwKLeP5MbtgLMtqBUDea+eELLTfv8kSJS1t2 0u2wFj8dANssFV5ghutw/CS8N7v9j/R6HptmrsXcvz3+RHEp81CIC39ZOAz40aIvkQtA aM3V1l/I/PBWrmnzcbBBOxAXtSOo7onIhf2nUqyJnFe1KeXK+p0XuXTKTedASRH9I+t5 TI+R740/wkMoo0KLfpwKBScJ0sCeUPQbZBvBv841qPjyhhZcNqmvSZMQpRmVEJxau8v4 J0vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=FscF0IDiMjkYGyFEyrGjTC5aofwZiC6ayHh3t28wK+4=; b=QnqQqHtwzlIoNQ4Nj+rxYmDK2gFa3NeBGxcv+4vj/WCClcmShBRCBN5dSP07iSpJlU S3mFjPv8eGzrp2PBw4BSEEl/0NJQWXKXbuNQODA59gToXSG4KyjRxZ6s3Xa8r4+rKVMs ZIwb8PdDxcoJSZwpnpa7NXwcWCrqVvZQbgoQoQarm9/RxZVB0udlluVkE1WqCye+00+5 plq/orSNA7YFfPIsj6FTUWIri3TEgSzrgunrwV7T5d3EI45nnqhxUin0AHpN5CNiI4pZ V+EM3lyapXRhW3fmNa2n9aSDqNrWVEVPskFsh6YsP+A0XMaDKRiByM9AEbabZNnHENCq MhGQ== X-Gm-Message-State: AOAM530VN5MVZKWSL6Hv8ZkKjbx0ubwcB+FlawPIKxFOIXBZSGRh+c96 MEHVChXeP8EpR5gfYqgvnvk= X-Google-Smtp-Source: ABdhPJz8+97pNVvYywT/H4dM5GJSJiOVnduIhvJLmHoYq75KVkEZD3BCOHPWDxjNPebtTf6T6v6tVA== X-Received: by 2002:a05:6512:1196:: with SMTP id g22mr10491075lfr.189.1614644574066; Mon, 01 Mar 2021 16:22:54 -0800 (PST) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id p3sm2425916lfu.271.2021.03.01.16.22.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Mar 2021 16:22:53 -0800 (PST) Date: Tue, 2 Mar 2021 03:22:51 +0300 From: Dmitry Kozlyuk To: Nick Connolly Cc: Bruce Richardson , dev@dpdk.org, Tyler Retzlaff , Jerin Jacob , Sunil Kumar Kori Message-ID: <20210302032251.0cd592f3@sovereign> In-Reply-To: <87502441-f319-2436-8cbc-c6529982b9cd@mayadata.io> References: <20210220232910.772-1-dmitry.kozliuk@gmail.com> <20210221012831.14643-1-dmitry.kozliuk@gmail.com> <20210221012831.14643-2-dmitry.kozliuk@gmail.com> <20210222114743.GA1235@bricha3-MOBL.ger.corp.intel.com> <64c1e6c5-ce80-b550-b8ea-ad2a6bfe7505@mayadata.io> <20210222142625.GA704@bricha3-MOBL.ger.corp.intel.com> <20210223015750.31516c2c@sovereign> <20210223094502.GB79@bricha3-MOBL.ger.corp.intel.com> <20210227232327.1ac69729@sovereign> <87502441-f319-2436-8cbc-c6529982b9cd@mayadata.io> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 1/7] eal: add wrappers for POSIX string functions 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 Sender: "dev" 2021-03-01 21:31, Nick Connolly: > > There's a meson issue with `cc.has_function()`: > > https://github.com/mesonbuild/meson/issues/5628 > > > > What if we just define RTE_INTERNAL for librte_eal/windows/include/rte_os.h > > (and other public headers if need be) to distinguish the case when it's used > > from within DPDK? > It's a pragmatic solution to the problem, but sadly it's not quite as > clean as letting the build system determine if each 'wrapper' is needed. > DPDK supports a variety of platforms and toolsets and my experience with > SPDK suggests that we'll end up with compiler specific ifdef's. I'd argue they are inevitable. Consider POSIX close(): if it's missing, what would be a correct fallback? It depends on the execution environment (OS). String function fallbacks, of course, are easily implemented from scratch. > It's all > protected by RTE_INTERNAL so it's not really a problem, but I wonder if > it makes it easier for someone to accidentally introduce definitions > outside of the #ifdef RTE_INTERNAL? Public functions without rte_ prefix shall not be introduced at all. Remember the issue this patchset targets: export of POSIX symbols from EAL. They are already defined in a way DPDK consumes successfully. RTE_INTERNAL is a straightforward way to ensure symbols affect to other consumers. (I'm talking about macros; asprintf should be moved inside EAL in any case.)