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