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 7F547A054F; Mon, 1 Mar 2021 22:31:12 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0682E4069E; Mon, 1 Mar 2021 22:31:12 +0100 (CET) Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by mails.dpdk.org (Postfix) with ESMTP id 1691F40041 for ; Mon, 1 Mar 2021 22:31:10 +0100 (CET) Received: by mail-wm1-f54.google.com with SMTP id e23so528265wmh.3 for ; Mon, 01 Mar 2021 13:31:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mayadata-io.20150623.gappssmtp.com; s=20150623; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=H7hPqS/Yz89GUxu7z3eFyvxcfj8rwkoVRwpHbPJh814=; b=2K5U0fadgTZBEImssc0dDSzRZazLT0CWiJ/M9lh/pY3dNjikFPZwsefQjntHz9dbJG bSN9wc5S7b2cyPmiQKMWLny/n5+CZB3FF2PJzQwCe6HZsHblIZPxcGXH7XcIX9EaaeFS G18axVXzbxXVKy4o3wW7Jf2rgnGHzgViix6RPxmwuhkmMpmB6uYbxiEb3jot3UGtRTkn DPZlzdJjCg9kUsmGrChsBbGoRqi7JPAeToYEFrE1/6T+rVMWdxT0Lo/2Lwqkgq8njUoJ 7zMxobHM+rhbf1vzig7uwIGhwCY9xxGiAteugOUvR9A6yz9QSyNN1o3Dwe96U0pojWXX 4S+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=H7hPqS/Yz89GUxu7z3eFyvxcfj8rwkoVRwpHbPJh814=; b=IDjHbtieCTi65jjidd3xMLT1fnSky9bGKzlB+l0fqT1lA82xuljSx8tcJid73U9cpO sp11RcC5TUk9Nv9qwCKeS0hu3cfx6kCaj7nPm0vGhoJzLLzcSXFEJXhOQ4s9gkTPqDwx O1o28CMuRrwddbbA+tzhhhtgUQmwFXkCM/7Y79fn9sQyx0IntP6HHE6SeWtCTb1H3jdD ASYVeFybjUx4n5uwymew3lganx9BSxG0E/lVXkBvCMPXF/N4Z9Au9Exu08GYI9rmGt94 9ZoaAxJg61d6Yglc/ks2lYI7LzNpaNa7pkrmfGkDoFCoBAH5Ujce0nF08frBxeiON+9g O8Jg== X-Gm-Message-State: AOAM531dEkmFMGTlF7gFVk12gBzRyT1qHL07qaUzMC5XayHjUZI2xGXo tXhCSn0rMeHyR9Mpw69bdaQ5MA== X-Google-Smtp-Source: ABdhPJz8GoV+ugD+4ixgIfcTYXEv6G26m2Oo8BXLgpRWuYBBtC0uKkKk5rOJp3fg8AMlOOQHnf3QTQ== X-Received: by 2002:a1c:9a47:: with SMTP id c68mr732065wme.63.1614634269732; Mon, 01 Mar 2021 13:31:09 -0800 (PST) Received: from [192.168.0.33] (cpc98320-croy25-2-0-cust77.19-2.cable.virginm.net. [80.235.134.78]) by smtp.gmail.com with ESMTPSA id r2sm6627669wrt.8.2021.03.01.13.31.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Mar 2021 13:31:09 -0800 (PST) From: Nick Connolly X-Google-Original-From: Nick Connolly To: Dmitry Kozlyuk , Bruce Richardson Cc: dev@dpdk.org, Tyler Retzlaff , Jerin Jacob , Sunil Kumar Kori 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> Message-ID: <87502441-f319-2436-8cbc-c6529982b9cd@mayadata.io> Date: Mon, 1 Mar 2021 21:31:07 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210227232327.1ac69729@sovereign> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB 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" > 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. 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? How about a new header rte_os_internal.h that contains the 'wrappers'? It gets included from rte_os.h only if RTE_INTERNAL is set and doesn't get installed so can't impact the user environment. I'm not sure I like it, but I guess we could do the same thing for every header that needs wrappers. I'm really 'thinking aloud' here and I'm not convinced it's the best route forward, so feel free to ignore. What I'm searching for is a way of wrapping that's clean and has a reasonably low risk of future human error. Regards, Nick