Hello Eitan, Two pair of eyes are better than one! Anyway, reading a bit further of what you read:
"The "only NDIS APIs" rule is meant to cover areas that are more central to networking, like DMA, interrupts, DPCs, and IRPs. For that sort of thing, miniport drivers must either go through NDIS, or register themselves as a NDIS-WDM miniport. (The rule completely goes away for NDIS-WDM miniports; the network HCK tests will only verify that you don't call a few blacklisted APIs like DbgPrint.)" It makes somewhat a bit of sense, since WHQL certification stands for "Windows Hardware Quality Labs". It appears this rule is in place for miniport drivers. I have also found these: http://msdn.microsoft.com/en-us/library/windows/hardware/ff553976(v=vs.85).aspx http://msdn.microsoft.com/library/windows/hardware/hh833788.aspx http://msdn.microsoft.com/en-US/library/windows/hardware/jj128255.aspx They may be useful for us to study one day :) Sam ________________________________________ From: Eitan Eliahu [elia...@vmware.com] Sent: Wednesday, August 06, 2014 7:04 PM To: Samuel Ghinet; dev@openvswitch.org Subject: RE: [PATCH] datapath-windows: Add Core.h Sam, I think Microsoft official recommendation is to NDIS wrapper calls (for certification). I came across the following when I read same the thread you pointed out: "I remember an invigorated discussion here some time ago regarding the necessity to use NDIS APIs inside NDIS drivers in order to acquire WHQL certification" Thanks, Eitan -----Original Message----- From: Samuel Ghinet [mailto:sghi...@cloudbasesolutions.com] Sent: Wednesday, August 06, 2014 8:53 AM To: Eitan Eliahu; dev@openvswitch.org Subject: RE: [PATCH] datapath-windows: Add Core.h Hello Eitan, Just found this (it is an answer on a thread, not true doc, but may be helpful): "I would actually suggest avoiding the NdisAllocateMemory* APIs for general pool allocations, and going straight to the ExAllocate APIs. There's nothing interesting going on in the NDIS APIs, and the kernel ones are better-documented and slightly better-designed. (For DMA memory, you will still have to go through NDIS, though.)" (https://urldefense.proofpoint.com/v1/url?u=http://social.msdn.microsoft.com/Forums/windowsazure/en-US/666f4fd4-acc7-47ea-958b-4fdb08b02e70/ndis-memory-management-functions-intrerchangeability&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yTvML8OxA42Jb6ViHe7fUXbvPVOYDPVq87w43doxtlY%3D%0A&m=%2ByyNhbCNUBYr3GmzuA%2ByngpjnCLL7ndWQtz%2FELeq5%2Fg%3D%0A&s=091d38e1cf10c13a69021c3940ebb34aca77345ef25a74dfdf976353b840829c) This guy, Jeffrey Tippet, is apparently working at microsoft, and also gives answers on osronline. I'm just saying, perhaps he's right :) Sam ________________________________________ From: Eitan Eliahu [elia...@vmware.com] Sent: Wednesday, August 06, 2014 6:22 PM To: Samuel Ghinet; dev@openvswitch.org Subject: RE: [PATCH] datapath-windows: Add Core.h Hi Sam, Since the switch extension driver is an NDIS filter driver it would be preferable to use NDIS memory allocation functions rather direct executive system calls. On another thing: since this driver is basically two combined drivers (Extension and WFP) it would be nice if we could pass the tag used by the memory allocation function as a parameter. Beside the extension and the WFP, we would like to be able to distinguish between memory blocks allocated during initialization and memory allocated during the fast path. Thanks, Eitan -----Original Message----- From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Samuel Ghinet Sent: Wednesday, August 06, 2014 7:55 AM To: dev@openvswitch.org Subject: [ovs-dev] [PATCH] datapath-windows: Add Core.h Add Core.h Functionalities & macros that are expected to be needed / used anywhere. Such as: macros for memory allocations. These would replace the memory allocations functions defined in Utils.c: * There is no need to allocate memory with priority if priority = normal (default) * There is no need to use the Ndis mem allocation function, which requires an NDIS_HANDLE, when we can use the Executive mem allocation function (ExAllocatePoolWithTag) which does not. * There is no need to do a check like "OVS_VERIFY_IRQL_LE(DISPATCH_LEVEL)": the maximum IRQL that we can have in the driver is dispatch level. * OVS_ALLOC, OVS_FREE and KZAlloc are shorter-named, improving the code clarity. Signed-off-by: Samuel Ghinet <sghi...@cloudbasesolutions.com> --- datapath-windows/ovsext/Core/Core.h | 55 ++++++++++++++++++++++++++ datapath-windows/ovsext/ovsext.vcxproj | 1 + datapath-windows/ovsext/ovsext.vcxproj.filters | 5 ++- datapath-windows/ovsext/precomp.h | 1 + 4 files changed, 61 insertions(+), 1 deletion(-) create mode 100644 datapath-windows/ovsext/Core/Core.h diff --git a/datapath-windows/ovsext/Core/Core.h b/datapath-windows/ovsext/Core/Core.h new file mode 100644 index 0000000..3c56a13 --- /dev/null +++ b/datapath-windows/ovsext/Core/Core.h @@ -0,0 +1,55 @@ +/* +Copyright 2014 Cloudbase Solutions Srl + +Licensed under the Apache License, Version 2.0 (the "License"); you may +not use this file except in compliance with the License. +You may obtain a copy of the License at + +http ://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, software +distributed under the License is distributed on an "AS IS" BASIS, +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +See the License for the specific language governing permissions and +limitations under the License. +*/ + +#pragma once + +#include "precomp.h" + +//used in ASSERT-s +#define __NEVER_TRIED_THIS__ 0 +#define __NOT_IMPLEMENTED__ 0 +#define __UNEXPECTED__ 0 + +#define OVS_ALLOC(size) ExAllocatePoolWithTag(NonPagedPool, size, +OVS_MEMORY_TAG) #define OVS_FREE(p) KFreeSafe(p) + +#define OVS_ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0])) #define +OVS_CONST_CAST(p) ((VOID*)p) + +#define OVS_SIZE_ALIGNED_N(dataSize, N) (((dataSize) / (N)) * (N) + ((dataSize) % (N) ? (N) : 0)) +#define OVS_SIZE_ALIGNED_4(dataSize) OVS_SIZE_ALIGNED_N(dataSize, 4) +#define OVS_SIZE_ALIGNED_16(dataSize) OVS_SIZE_ALIGNED_N(dataSize, 16) +#define OVS_SIZE_ALIGNED_MEM(dataSize) OVS_SIZE_ALIGNED_N(dataSize, MEMORY_ALLOCATION_ALIGNMENT) + +static __inline VOID* KZAlloc(SIZE_T size) { + VOID* p = OVS_ALLOC(size); + if (!p) + { + return NULL; + } + + RtlZeroMemory(p, size); + return p; +} + +static __inline VOID KFreeSafe(VOID* p) { + if (p) + { + ExFreePoolWithTag(p, OVS_MEMORY_TAG); + } +} diff --git a/datapath-windows/ovsext/ovsext.vcxproj b/datapath-windows/ovsext/ovsext.vcxproj index 2c62cab..ee69327 100644 --- a/datapath-windows/ovsext/ovsext.vcxproj +++ b/datapath-windows/ovsext/ovsext.vcxproj @@ -70,6 +70,7 @@ <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" /> </ImportGroup> <ItemGroup Label="WrappedTaskItems"> + <ClInclude Include="Core\Core.h" /> <ClInclude Include="Core\Debug.h" /> <ClInclude Include="Core\Error.h" /> <ClInclude Include="Core\FixedSizedArray.h" /> diff --git a/datapath-windows/ovsext/ovsext.vcxproj.filters b/datapath-windows/ovsext/ovsext.vcxproj.filters index 96cfac6..78d041b 100644 --- a/datapath-windows/ovsext/ovsext.vcxproj.filters +++ b/datapath-windows/ovsext/ovsext.vcxproj.filters @@ -89,6 +89,9 @@ <ClInclude Include="Core\FixedSizedArray.h"> <Filter>Core</Filter> </ClInclude> + <ClInclude Include="Core\Core.h"> + <Filter>Core</Filter> + </ClInclude> </ItemGroup> <ItemGroup> <ResourceCompile Include="ovsext.rc" /> @@ -185,4 +188,4 @@ <Filter>Core</Filter> </ClCompile> </ItemGroup> -</Project> +</Project> \ No newline at end of file diff --git a/datapath-windows/ovsext/precomp.h b/datapath-windows/ovsext/precomp.h index 3fd5da2..b28e9ec 100644 --- a/datapath-windows/ovsext/precomp.h +++ b/datapath-windows/ovsext/precomp.h @@ -21,6 +21,7 @@ #include <ntstrsafe.h> #include <Strsafe.h> +#include "Core/Core.h" #include "Core/Debug.h" #include "Core/Types.h" #include "Core/Util.h" -- 1.8.3.msysgit.0 _______________________________________________ dev mailing list dev@openvswitch.org https://urldefense.proofpoint.com/v1/url?u=http://openvswitch.org/mailman/listinfo/dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yTvML8OxA42Jb6ViHe7fUXbvPVOYDPVq87w43doxtlY%3D%0A&m=yxTY3Wi7%2FFMeUWdPQfNNcLSgeCj1i4IUNumKniOlOAM%3D%0A&s=35a73bc26183ace9014c9d3bde3532ad0a7b0e813ec52efc35e107efed2631a2 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
