Re: Moving code into applications (was Re: Information on implementing L4)

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