From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2F326A00C2; Thu, 23 Apr 2020 03:00:47 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C01581D408; Thu, 23 Apr 2020 03:00:46 +0200 (CEST) Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) by dpdk.org (Postfix) with ESMTP id EB8831D173 for ; Thu, 23 Apr 2020 03:00:45 +0200 (CEST) Received: by mail-lf1-f65.google.com with SMTP id m2so3345943lfo.6 for ; Wed, 22 Apr 2020 18:00:45 -0700 (PDT) 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=XlYS/1lLY1A+5HidLgxjd+T++QpnQuChb868eSiIZ90=; b=M9P99uhX9wKfjQxlBYcq1E/yUs/60jXUq10cdEOquFCcS9N1EcNqWoViSE1kw7dZzg wBOwnhLxSYY4bQrecJ4Rf9R03LlUt5sguXvTQHztxAPPUlHoG6FFqcS62mRJq5UeN0Y3 99726g40JvJxWZ+rYe2FobTH00Fr+Yr0sGKw11Pii2b1b4OwGtbl51qKTl65+PoKqQmC vkXFuHhFJp++t886Hed+dyxwisJD88f6T+Pl0VgDUPOfXUB7fzpih3wyM9vlJpVf4WBg E1EIMiJjsAle72ABTSdC2xRMs5925GbQlCQ2bVmnB27XrJyHAgjNMzXiQS/f9qHGpfKU 0RkA== 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=XlYS/1lLY1A+5HidLgxjd+T++QpnQuChb868eSiIZ90=; b=fgqeunIM00tzx5EuWwT6FRnSPxVP7qtTZ5eS81OyAM/Xek5atCy7KTLvx7+PVvghgm PO1fyxWjE8QuXIw5Nz907gFbDML5LQFcOvLFYHshARUyBUKd6cG9e60Zc9x/hHQ+hvO9 KPfjPOPfiu7nD20VYYC1yyJo/HYP0puSccuXPbzggCixAi2Lqrc2kU+i1m9IC8QkASl4 mWYgA/wvUEL27ooqeJF3umNfMXPzRQjSfvjIW5sHG4IPSuZm0Pb7Vcb5GW/feiYotFUU w6cvLsq1U464fqOAHPOP3mqrT7CEmgPgQK9/MRjtqa0eRZ/sqRvqhR6MHfduGGEFbyUf M+IA== X-Gm-Message-State: AGi0PubTpJC9UW2TAlU2l+VnDz1QBlL9ewr3CJpQvNFNd60Jqc8f68lV procFqsRe/9Vf1MTOm8xt6E= X-Google-Smtp-Source: APiQypLL8nqJ7cFQlWAp9PvZq/Ef0PO5929e+KZAG7KCmJ6ja6bVdJV9hQiyHT5LuaRKWrxWiOM32Q== X-Received: by 2002:ac2:5395:: with SMTP id g21mr750335lfh.61.1587603645355; Wed, 22 Apr 2020 18:00:45 -0700 (PDT) Received: from Sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id v8sm506597lfp.85.2020.04.22.18.00.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Apr 2020 18:00:44 -0700 (PDT) Date: Thu, 23 Apr 2020 04:00:43 +0300 From: Dmitry Kozlyuk To: Ranjit Menon Cc: "dev@dpdk.org" , "Dmitry Malloy (MESHCHANINOV)" , Narcisa Ana Maria Vasile , Fady Bader , Tal Shnaiderman , Thomas Monjalon , Harini Ramakrishnan , Omar Cardona , "Kadam, Pallavi" , "Mcnamara, John" , "Kovacevic, Marko" , "Burakov, Anatoly" , "Richardson, Bruce" Message-ID: <20200423040043.31429902@Sovereign> In-Reply-To: References: <20200410164342.1194634-1-dmitry.kozliuk@gmail.com> <20200414194426.1640704-1-dmitry.kozliuk@gmail.com> <20200414194426.1640704-11-dmitry.kozliuk@gmail.com> X-Mailer: Claws Mail 3.17.5 (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 v3 10/10] eal/windows: implement basic memory management X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" On 2020-04-16 11:34 GMT-0700 Ranjit Menon wrote: [snip] > > --- /dev/null > > +++ b/lib/librte_eal/windows/include/rte_virt2phys.h [snip] > > This file is a duplicate of: : windows/virt2phys/virt2phys.h > This is by design, since it documents the driver interface. > > So, to prevent the two files going out-of-sync, should we: > 1. Make the two filenames the same? > 2. Add comments to both files referencing each other and the need to > keep them both in sync? > 3. Do both (1) and (2)? > > This will also be an issue for the upcoming Windows netuio kernel driver > and I reckon this could be an issue for Linux kernel modules too. > > Thoughts? I guess it won't be much of an issue in practice. When you edit driver interface you're already considering user-mode and kernel interaction, by definition of that interface, so you can't forget about the counterpart. I'd be more worried about ABI, because memory corruption in driver will crash the system, being hard to debug. Can we leverage abigail for these interfaces? -- Dmitry Kozlyuk