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 _______________________________________________ Genode users mailing list [email protected] https://lists.genode.org/listinfo/users
