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 014EEA034F; Wed, 31 Mar 2021 23:05:31 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8603D140EB8; Wed, 31 Mar 2021 23:05:31 +0200 (CEST) Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by mails.dpdk.org (Postfix) with ESMTP id 7650E140EB7 for ; Wed, 31 Mar 2021 23:05:30 +0200 (CEST) Received: by mail-wr1-f49.google.com with SMTP id v11so20963615wro.7 for ; Wed, 31 Mar 2021 14:05:30 -0700 (PDT) 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=cqffVBMwNTNIVrVg6bW9dTCeX6F2v9vyUwA9x5NoTP0=; b=DECSLXL5WTRZufX9A74/TgL5X+fXVC+A8gGKdfYCdz0xIE02u/Mc/i5tJeEFBO0/G3 /4OSmIM3XAr8JNI5y0+JkQC3oDE5ScbYeR9RZI0Hu8Vdp4Z580i9Zo9zcKn1yZMs+6nM EYSmRP8F51tq2Bem0xuBVZcbPCXTAAQWJDid9W4XQUnLfgOxOTlKtW1Uyoz7oAoJ29WQ 1ZUkX1NMcnnUzhF8XZhTuJtm9wXeSffyNYzvRSFd3t342X7Qd3w8jdAJSxt0wwyQ6MGG O2P3UEIzJz9aNVZlw9BZUduT4ZeamO78mVCAebN1p5Mo9YXhxemIbq1kcc9ZoFZKZRnx 9rZQ== 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=cqffVBMwNTNIVrVg6bW9dTCeX6F2v9vyUwA9x5NoTP0=; b=P0KKXCkHEsqXx8JHhh195oTrTr29g+V9SxQHYX4zBSLWMeCoSOswFKzAFevSyFZSws Dgvs6jS7DCNObTgtb/KO13401Pt7whgWg38bG0I9tSRaF8JxRbupE1GzwQEaQaodRpBF VLFh5TfHQHFOQGAT+z83gHNaR5SS3UD3iX4bUcjY8rqDMy4v2F5njBIjyUqBpbECbRk2 7Z1i/ZzD2RzD3F6y8m7s6KGZJRQmn3h8aRISs9Dyr01CQ3arcOINprF75ilKRxWfxWKj hEZi21SZdRJmYId4lMC39mKNL7Z+jlBwE8reDFQTF7OzxjzJJEE2ge/0eu8Zx+MQrB/o dxAw== X-Gm-Message-State: AOAM532HrxaV9yqvok/Y8xuc7MKuCf9BccB+6Z2uWPaWMRHcczHwLvlR AlkrweuLSWW/KpjTMDgT7qu99Q== X-Google-Smtp-Source: ABdhPJwLaX9KC3iGTQTCOGqrdNYy1EYQKzMAz5+ef9ZaW1aaPWjEprPQk84/q8PahpLHeJC1Mqw/Vw== X-Received: by 2002:adf:dd4f:: with SMTP id u15mr5880113wrm.260.1617224730155; Wed, 31 Mar 2021 14:05:30 -0700 (PDT) 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 i8sm6420313wrx.43.2021.03.31.14.05.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 31 Mar 2021 14:05:20 -0700 (PDT) From: Nick Connolly X-Google-Original-From: Nick Connolly To: Thomas Monjalon , Dmitry Kozlyuk Cc: dev@dpdk.org, Tyler Retzlaff , Jie Zhou , Olivier Matz , Bruce Richardson , Narcisa Ana Maria Vasile , Dmitry Malloy , Pallavi Kadam References: <20210320112733.13160-1-dmitry.kozliuk@gmail.com> <20210320130525.16452-1-dmitry.kozliuk@gmail.com> <20210320130525.16452-4-dmitry.kozliuk@gmail.com> <9009917.79gZZNtG4R@thomas> Message-ID: <8389a549-9aa1-5bf5-fbcc-9dffbab9fe06@mayadata.io> Date: Wed, 31 Mar 2021 22:05:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <9009917.79gZZNtG4R@thomas> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Subject: Re: [dpdk-dev] [PATCH v6 3/5] eal: make OS shims internal 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" > This shim could have been convenient for applications. > If not named "internal", we could export the header file > and allow apps including it. > > Otherwise the app can recreate this file on its side, > it is not a big deal. > Opinions? Based on my experience with SPDK, I believe this would get messy very quickly. For example, a common usage is to redefine close to _close. If the application is going to use sockets without requiring changes, then a fake fd is needed to represent a socket and close has to handle it as well ... which will clash with the 'simplistic' redefinition to _close, so we'd need some way of turning these on/off individually. I think there are really only two models that are viable - either an external POSIX layer that is used by everything (in the general case, Cygwin would be an example), or a private implementation that is not exposed publicly. Keeping the implementation private is not just about keeping POSIX out of the headers. It's about avoiding conflicts with the application; e.g. making sure that any signal implementation can co-exist with the application. Regards, Nick