Sorry to hold off responding for so long!
On Monday 17. September 2018 16.54.14 Andrew Warkentin wrote:
UX/RT will use a split architecture for its VFS, where read(), write(), and seek() will call kernel IPC APIs to communicate with the server directly, and all other filesystem-related functions will call the VFS component in the process server. This seems to be the easiest way to implement a VFS architecture that maps each file descriptor onto a capability (actually, a group of related capabilities) while still having reasonable performance.
I sent a mail about filesystem design choices to this list back in August, but I guess all the action is elsewhere with regard to people writing code for these systems:
https://os.inf.tu-dresden.de/pipermail/l4-hackers/2018/008303.html
Recent experiments of mine have focused on separating client functionality (below the C library level, in practice) from filesystem operations (implemented in their own server) and from block device operations (also in their own server, currently faked using access to "rom" files in L4Re). The objective here was to explore mechanisms for sharing buffers between processes and figuring out what the communication has to be.
What I want to do in future is to switch out the VFS code and library functionality up to and including the C library, with musl-libc looking like a fairly clean basis for doing that. However, this is probably going to be a lot of work.
Still, I hope to look a bit more closely at MINIX 3 and the Hurd (on Mach and on L4) to see what patterns have been employed previously. I gave some relevant links to documentation in my previous message (see above).
Paul