1:02 p.m.
Thank you for the response.
Fortunately I don't think I need FSAL_VFS. My goal is to create an in-memory
filesystem in order to benchmark macOS's NFS client. I essentially want to create
a more specialized FSAL_MEM. If I understand the NFS-Ganesha architecture
properly, FSAL_VFS is not needed since I don't care about a concrete POSIX
filesystem.
Here are a few things I'm hacking around to get things building, and I hope to
have some results in the next few days:
- The Apple "ld" doesn't support --version-script=, so it must be switched
to use
-exported_symbols_list
- The build system assumes the URCU library header files are in the search path
by default, which is not the case with homebrew.
- We must use EPOLL emulation (using kqueue) which was originally written for
FreeBSD
- I changed several #include lines from <gssapi/foo.h> to <GSS/foo.h> to
get
around compiler errors though I'm not sure if this actually solved anything :)
- Redefining of strlcpy and strnlen
- Some atomic_fetch_* functions are not defined properly
Ok, if you just want to use FSAL_MEM you should have a much easier time. What changes do
you want to make to it? It was developed to be able to test latency in the Ganesha stack
without having to factor in latency of the back end filesystem, so if you have additional
testing needs for it, let's talk about incorporating them.
Once you get it working, can you commit to supporting it? None of us in the current active
development community use Macs so our ability to keep it working will be limited.
Frank