On Mon, May 19, 2025 at 7:58 AM Chen Linxuan chenlinxuan@uniontech.com wrote:
On Thu, May 15, 2025 at 6:27 PM Amir Goldstein amir73il@gmail.com wrote:
On Thu, May 15, 2025 at 9:35 AM Chen Linxuan chenlinxuan@uniontech.com wrote:
ret = read(test_fd, path_buf, sizeof(path_buf));ASSERT_LT(ret, 0);Nice! I guess you could also verify errno == ENOTCONN or whatever it is in this case.
I am currently facing two issues:
- I am not sure about the exact functions of max_background and
congestion_threshold. I have prepared a patch that adds documentation for these two fields, which can be found here: https://lore.kernel.org/all/20250514061703.483505-2-chenlinxuan@uniontech.co...
It may be a bit challenging to design a test that does deterministic readahead, because there is usually no contract for readahead, so not sure.
- How should I test the "waiting" file? My current idea is to have my
FUSE daemon stay in a state where it does not respond to requests, and then use some form of inter-process communication (maybe a Unix socket?) to make it resume working. I am not sure if there is a better approach.
This is a good approach that several selftests use.
Looking at the bigger picture, your work to improve documentation and selftest coverage for fuse is very welcome! so I will add some wider context comments.
One small nit: please rename the test subdir to filesystems/fuse rather than filesystems/fusectl, so that more fuse selftests could be added later.
For the long run, I would consider a very minimal single threaded fuse server implementation that does not rely on libfuse for fuse selftests, because the selftest should not rely on the libfuse version installed on the development system and also testing low level protocol issues would require this anyway. But this is not a requirement for this first test.
Thanks, Amir.