Windows: SPDK backend support #275
Conversation
|
Yesterday the self-hosted xNVMe github-actions-runners were "migrated" from one hosting provider to another. To avoid blocking progress on this PR (#275), due to CI-failures, then this PR was rebased. Curiously, the rebase of this PR shows in a surprising way on the history. That is, the two commits introduced on #276 looks like they are part of the PR, as the first two commits. Even though they have the same SHAs as the commits on |
rs-sam
force-pushed
the
wpdk
branch
4 times, most recently
from
1395a6e to
8e5562a
Compare
safl
force-pushed
the
wpdk
branch
2 times, most recently
from
7a3d734 to
4fca490
Compare
|
HI @rs-sam I rebased this, to get the changes to work around the ci-blockage. |
|
I have rebased this PR with latest next. It has a new issue that is latest SPDK repo has a non windows friendly file name "https://github.com/spdk/spdk/blob/master/test/common/config/pkgdep/patches/ice/0001-stats-fetch_*_irq.patch" |
|
To resolve the issue of: Caused by the patch-file not being compatible with WIndows FS, then let's try:
|
There was a problem hiding this comment.
To avoid multiple SPDK subprojects e.g. subprojects/spdk and subprojects/spdk-win then it would be great to combine these into a single subproject.
However, ss I understand it then WPDK currently uses v22.05 and xNVMe uses v22.09.
Thus, we need to track to different SPDK versions. Let's make sure this is documented, and then we should work on updating both xNVMe and WPDK to the latest SPDK version v23.??.
subprojects/packagefiles/wpdk/patches/wpdk-0001-fixed-clang-compilation-warning.patch
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Code LGTM, however, we seem to face some CI issues with this.
I would propose:
- Remove call of
xnvme enum - Fix what is causing
xnvme library-infoto fail - Drop support / testing for Windows 2019
- Remove from .gtihub workflow, documentation, etc.
- Determine whether this can be built using
clanginstead ofgcc- Compilation issue needs to be resolved
- advantage: "direct" use of
clang+meson - advantage: we would not need to use wsl
- advantage: a lot of scripts patching dos2unix etc. would no longer we needed
rs-sam
force-pushed
the
wpdk
branch
2 times, most recently
from
809918c to
fc64fdf
Compare
safl
force-pushed
the
wpdk
branch
3 times, most recently
from
9a9ad50 to
e42ddcd
Compare
Including WPDK and SPDK backend, it works to expose spdk as one the backend on windows machine. Signed-off-by: Rishabh Shukla <rishabh.sh@samsung.com>
current spdk master repo is not compatiable for Windows FS, thats why changing it to older forked repo. Signed-off-by: Rishabh Shukla <rishabh.sh@samsung.com>
After adding changes related to WPDK and SPDK, Windows 2019 have some header related compilation errors. Looks like it has compatibility issue, which is not fixable. Signed-off-by: Rishabh Shukla <rishabh.sh@samsung.com>
Signed-off-by: Rishabh Shukla <rishabh.sh@samsung.com>
The enumeration functions allocate virtual memory using what matches the platform via the backend. However, when this memory was free'd, then it was done using free(). This fixes it for the use in the xNVMe command-line tool. Signed-off-by: Simon A. F. Lund <simon.lund@samsung.com>
Adding support for SPDK backend for Windows OS, using WPDK repo.
Have a look at this initial work to do support SPDK backend for xNVMe on Windows OS.
Created a new subproject called 'spdk-win'. It used mix environment MSYS2-MinGW and WSL for the compilation.
A helper 'spdk_win_build.bat' batch file is used to do compilation of dependency repos like
WPDK, DPDK and SPDK.