2021-09-08 15:14 (UTC-0700), Jie Zhou: > On Tue, Sep 07, 2021 at 09:43:56AM -0400, Aaron Conole wrote: > > Jie Zhou <j...@linux.microsoft.com> writes: > > > > > Enable a subset of unit tests on Windows. Currently not all the > > > dependencies (e.g. libraries and some functionalities) of all unit > > > tests are supported on Windows yet. > > > > > > Signed-off-by: Jie Zhou <j...@linux.microsoft.com> > > > --- > > > > Hi Jie, > > > > How is it expected that a developer will add unit tests here? For > > example, let's pretend I develop some new test. Do I insert it into the > > non-windows section or the 'all' section? Will it ever be moved common > > (for example, do windows development team aim to provide some additional > > test / review cycles for new tests added)? This have some implication > > on how developers need to add tests - maybe there can be a documented > > process for getting code more common (between windows / linux / > > freebsd)? > > > > -Aaron > > > > PS: I would suggest a possible route is to update to the doc proposed in > > http://patches.dpdk.org/project/dpdk/patch/20210714164047.511561-1-acon...@redhat.com/ > > but it still isn't merged. > > Thank you Aaron for bringing up this great question! Totally agree that we > need some discussion on what is the expectation for onboarding new unit tests > from different OS teams. For new tests that definitely missing supports on > certain OS(s), should it be authored in a way for across all OSs but skip not > supported ones at the beginning? Or just onboard for supported OS thus only > add to the non-windows section for example, and later DPDK Windows team move > it to common section after porting? I will bring this up in DPDK Windows > Community meeting and discuss there first. Yes, we should update the doc > (after your change merged) on the process once reaching some agreement.
Hi Aaron, Jie, Currently tests that should not run on certain platforms are disabled with #ifdef. This has an advantage that these tests mark themselves as skipped. There are no principal objections against this approach instead of many lists. Many tests files will need to be modified, but only mechanically. New tests for generic features should be cross-platform by default; why not? An exception I can think of is EAL that may implement some new API only for one OS. In this case the best we can do is to make sure the test code is not inherently bound to some OS. This is something we can document. For example, it should use <rte_ip.h> instead of including Unix network headers directly.
