Moving code into applications (was Re: Information on implementing L4)
paul at boddie.org.uk
Fri Oct 5 17:24:02 CEST 2018
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
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
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).
More information about the l4-hackers