Hi Alexander,
thanks for taking the time to reply.
After that, the started container is merely a standard process that has been encapsulated with namespaces, cgroup and other isolation mechanisms. The process performs syscalls just like a non-containerised process would do.
definitely so. while there are something «around» process - e.g. a way to execute process inside existing container, error handling/etc
In my view, a container maps in Genode to a subsystem (comprising a VFS server and other infrastructure). Hence, starting a process inside an existing container should be pretty straightforward.
Regarding the file system virtualisation, we have the VFS and can even host a shared VFS in a dedicated server component. I'm not sure about a copy-on-write feature, though.
main idea of sharing was scalability. What happens if we will try to run the same executable (e.g. Apache with 10M code) in 2 different containers ? if this is VM like containers then with big probability we will not share the code pages (e.g. for Windows some of the DLL code pages do contain variables, so, even for the same executable pages content could be different). imagine you have 100 containers with apache. they will eat 10m x 100 = 1GB of ram just for code pages. while could only 10m
I believe sharing code pages in Genode would be a matter of the parent component who sets up the children's address spaces. Currently, we use the sandbox library for this.
Another problem is a memory distribution. imagine that you have, for example, kernel object descriptor of 25 bytes, and a lot of them. if you have single os image then you have single memory allocator (if this is linux- slab/slub/etc) when you could store object instances related to different containers on the same memory page.
if you have own copy of everything - again, you will not just only inefficiently waste the kernel memory space for unused tails, but also will spend memory bandwidth/etc.
if we want to share effectively files they should be visible with the same «inode» (or similar, depending upon a file system) then instance of file system should be visible from every container via single FS instance. it should handle COW as well.
I think this is exactly what a VFS server component does. It provides a File_system service to which multiple components can connect.
- Implementing a container runtime for Genode that sets up a
sub-init to launch the container process with the appropriate VFS and helper components according to the container configuration.
again, same question like above. typically you could use something like tinit (tiny init) for such purposes, while it is not mandatory and for many apps it will work without. but you need to understand what will be with child processes inside container, who will own them after death of parent (or this should not happens and you can use app itself as pseudo init).
Sorry, I was not crystal clear in my terminology. By "sub-init", I meant Genode's init component that we use for spawning subsystems. Honestly, I haven't spent any thought on multi-process containers. I had the impression that most commonly a container merely runs a single process, i.e. does not spawn new processes on its own.
Best regards Johannes