| Message ID | 20230220100815.1624266-1-bin.meng@windriver.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | hw/9pfs: Add 9pfs support for Windows | expand |
On Mon, Feb 20, 2023 at 6:10 PM Bin Meng <bin.meng@windriver.com> wrote: > > At present there is no Windows support for 9p file system. > This series adds initial Windows support for 9p file system. > > 'local' file system backend driver is supported on Windows, > including open, read, write, close, rename, remove, etc. > All security models are supported. The mapped (mapped-xattr) > security model is implemented using NTFS Alternate Data Stream > (ADS) so the 9p export path shall be on an NTFS partition. > > 'synth' driver is adapted for Windows too so that we can now > run qtests on Windows for 9p related regression testing. > > Example command line to test: > "-fsdev local,path=c:\msys64,security_model=mapped,id=p9 -device virtio-9p-pci,fsdev=p9,mount_tag=p9fs" > > Changes in v5: > - rework Windows specific xxxdir() APIs implementation > > Bin Meng (2): > hw/9pfs: Update helper qemu_stat_rdev() > hw/9pfs: Add a helper qemu_stat_blksize() > > Guohuai Shi (14): > hw/9pfs: Add missing definitions for Windows > hw/9pfs: Implement Windows specific utilities functions for 9pfs > hw/9pfs: Replace the direct call to xxxdir() APIs with a wrapper > hw/9pfs: Implement Windows specific xxxdir() APIs > hw/9pfs: Update the local fs driver to support Windows > hw/9pfs: Support getting current directory offset for Windows > hw/9pfs: Disable unsupported flags and features for Windows > hw/9pfs: Update v9fs_set_fd_limit() for Windows > hw/9pfs: Add Linux error number definition > hw/9pfs: Translate Windows errno to Linux value > fsdev: Disable proxy fs driver on Windows > hw/9pfs: Update synth fs driver for Windows > tests/qtest: virtio-9p-test: Adapt the case for win32 > meson.build: Turn on virtfs for Windows Ping?
On Monday, February 20, 2023 11:07:59 AM CET Bin Meng wrote: > At present there is no Windows support for 9p file system. > This series adds initial Windows support for 9p file system. > > 'local' file system backend driver is supported on Windows, > including open, read, write, close, rename, remove, etc. > All security models are supported. The mapped (mapped-xattr) > security model is implemented using NTFS Alternate Data Stream > (ADS) so the 9p export path shall be on an NTFS partition. > > 'synth' driver is adapted for Windows too so that we can now > run qtests on Windows for 9p related regression testing. > > Example command line to test: > "-fsdev local,path=c:\msys64,security_model=mapped,id=p9 -device virtio-9p-pci,fsdev=p9,mount_tag=p9fs" > > Changes in v5: > - rework Windows specific xxxdir() APIs implementation I didn't have the chance to look at this v5 yet. In general it would help for review to point out in the cover letter which patch(es) have changed, what decisions you have made and why. In this case I guess that's patch 4. Best regards, Christian Schoenebeck > Bin Meng (2): > hw/9pfs: Update helper qemu_stat_rdev() > hw/9pfs: Add a helper qemu_stat_blksize() > > Guohuai Shi (14): > hw/9pfs: Add missing definitions for Windows > hw/9pfs: Implement Windows specific utilities functions for 9pfs > hw/9pfs: Replace the direct call to xxxdir() APIs with a wrapper > hw/9pfs: Implement Windows specific xxxdir() APIs > hw/9pfs: Update the local fs driver to support Windows > hw/9pfs: Support getting current directory offset for Windows > hw/9pfs: Disable unsupported flags and features for Windows > hw/9pfs: Update v9fs_set_fd_limit() for Windows > hw/9pfs: Add Linux error number definition > hw/9pfs: Translate Windows errno to Linux value > fsdev: Disable proxy fs driver on Windows > hw/9pfs: Update synth fs driver for Windows > tests/qtest: virtio-9p-test: Adapt the case for win32 > meson.build: Turn on virtfs for Windows > > meson.build | 10 +- > fsdev/file-op-9p.h | 33 + > hw/9pfs/9p-linux-errno.h | 151 +++ > hw/9pfs/9p-local.h | 8 + > hw/9pfs/9p-util.h | 139 ++- > hw/9pfs/9p.h | 43 + > tests/qtest/libqos/virtio-9p-client.h | 7 + > fsdev/qemu-fsdev.c | 2 + > hw/9pfs/9p-local.c | 269 ++++- > hw/9pfs/9p-synth.c | 5 +- > hw/9pfs/9p-util-win32.c | 1452 +++++++++++++++++++++++++ > hw/9pfs/9p.c | 90 +- > hw/9pfs/codir.c | 2 +- > fsdev/meson.build | 1 + > hw/9pfs/meson.build | 8 +- > 15 files changed, 2155 insertions(+), 65 deletions(-) > create mode 100644 hw/9pfs/9p-linux-errno.h > create mode 100644 hw/9pfs/9p-util-win32.c
On 6/3/23 15:15, Christian Schoenebeck wrote: > On Monday, February 20, 2023 11:07:59 AM CET Bin Meng wrote: >> At present there is no Windows support for 9p file system. >> This series adds initial Windows support for 9p file system. >> >> 'local' file system backend driver is supported on Windows, >> including open, read, write, close, rename, remove, etc. >> All security models are supported. The mapped (mapped-xattr) >> security model is implemented using NTFS Alternate Data Stream >> (ADS) so the 9p export path shall be on an NTFS partition. >> >> 'synth' driver is adapted for Windows too so that we can now >> run qtests on Windows for 9p related regression testing. >> >> Example command line to test: >> "-fsdev local,path=c:\msys64,security_model=mapped,id=p9 -device > virtio-9p-pci,fsdev=p9,mount_tag=p9fs" >> >> Changes in v5: >> - rework Windows specific xxxdir() APIs implementation > > I didn't have the chance to look at this v5 yet. > > In general it would help for review to point out in the cover letter which > patch(es) have changed, what decisions you have made and why. > > In this case I guess that's patch 4. FWIW the overall LGTM, but I'm not confident enough with Windows to add a R-b tag.
On Mon, Mar 6, 2023 at 10:15 PM Christian Schoenebeck <qemu_oss@crudebyte.com> wrote: > > On Monday, February 20, 2023 11:07:59 AM CET Bin Meng wrote: > > At present there is no Windows support for 9p file system. > > This series adds initial Windows support for 9p file system. > > > > 'local' file system backend driver is supported on Windows, > > including open, read, write, close, rename, remove, etc. > > All security models are supported. The mapped (mapped-xattr) > > security model is implemented using NTFS Alternate Data Stream > > (ADS) so the 9p export path shall be on an NTFS partition. > > > > 'synth' driver is adapted for Windows too so that we can now > > run qtests on Windows for 9p related regression testing. > > > > Example command line to test: > > "-fsdev local,path=c:\msys64,security_model=mapped,id=p9 -device > virtio-9p-pci,fsdev=p9,mount_tag=p9fs" > > > > Changes in v5: > > - rework Windows specific xxxdir() APIs implementation > > I didn't have the chance to look at this v5 yet. > > In general it would help for review to point out in the cover letter which > patch(es) have changed, what decisions you have made and why. > > In this case I guess that's patch 4. > Yes, it's patch 4, and v5 is reworked following your comments regarding patch 4 of v4. Regards, Bin
On Monday, March 6, 2023 3:56:49 PM CET Bin Meng wrote: > On Mon, Mar 6, 2023 at 10:15 PM Christian Schoenebeck > <qemu_oss@crudebyte.com> wrote: > > > > On Monday, February 20, 2023 11:07:59 AM CET Bin Meng wrote: > > > At present there is no Windows support for 9p file system. > > > This series adds initial Windows support for 9p file system. > > > > > > 'local' file system backend driver is supported on Windows, > > > including open, read, write, close, rename, remove, etc. > > > All security models are supported. The mapped (mapped-xattr) > > > security model is implemented using NTFS Alternate Data Stream > > > (ADS) so the 9p export path shall be on an NTFS partition. > > > > > > 'synth' driver is adapted for Windows too so that we can now > > > run qtests on Windows for 9p related regression testing. > > > > > > Example command line to test: > > > "-fsdev local,path=c:\msys64,security_model=mapped,id=p9 -device > > virtio-9p-pci,fsdev=p9,mount_tag=p9fs" > > > > > > Changes in v5: > > > - rework Windows specific xxxdir() APIs implementation > > > > I didn't have the chance to look at this v5 yet. > > > > In general it would help for review to point out in the cover letter which > > patch(es) have changed, what decisions you have made and why. > > > > In this case I guess that's patch 4. > > > > Yes, it's patch 4, and v5 is reworked following your comments > regarding patch 4 of v4. :) The point was we only discussed suboptimal individual options (each one with pros and cons), not one compelling solution. Never mind, I'll look at your code changes. Best regards, Christian Schoenebeck