Roadmap 2022

[Johannes Schlatow]

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.

> 
> > > 3. 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