Hi Everyone,
I am a student at Peking University in China. I am very interested in the
project of Cross Container
Support(http://wiki.gentoo.org/wiki/Google_Summer_of_Code/2012/Ideas#Cross_Container_Support).
I have some ideas about the project. Please help me to examine the thoughts.
First, I think downloading stage and portage packets into specified directory
each time needs to be
impoved(http://www.gentoo.org/proj/en/base/embedded/handbook/index.xml?part=1&chap=5).
It needs to build execution environment every time. So it is not convenient.
On the other hand, the files in specified directory would be modified by some
process potentially. It is not an isolated execution environment at all.
Therefore, I would make some img files for the each arch, including arm, mips,
etc. The img file contains arch-stage and portage. When creating the qemu-user
container, the iniscript mounts the img file into specified directory then
chroot to it.
Second, if the process accesses disk frequently, I would to make a tmpfs file
for the qemu-user container. The process in the container is running on tmpfs
file and been sped up.
Third, I would custom a lightweight qemu-user container for the specified
process if necessary. In my previous work, I made a custom ramdisk VM for the
process by modifying the mkinitrd script. With the help of “ldd –v ” command, I
could get the shared libraries of the process and packet them into ramdisk. But
in Gentoo, maybe I could custom the qemu-user container using the USE label.
In my proposal, this project uses a small quantity of bash to implement just
the core tools (create, destroy, enter). In simpler terms, I plan to implement
them in this way:
1. create routine
# qemu_container_create config_file
The config_file specifies arch, arch-img file, chroot directory, additional
args of qemu(like "-cpu cortex-a8"). Then the create routine will execute as:
1). If having the arch-img then mount it into chroot directory.
2). If not, make a new img file, download stageball&portage, unpack them to
the chroot directory.
2). modprobe binfmt_misc and register the qemu-user-arch to the binfmt_misc.
3). install the static qemu-user into the chroot directory and mount the
required directories.
4). register this new container to our managment tool. The register info
includes container_id, stageball version, stageball arch, chroot directory, etc.
2. enter routine
#qemu_container_enter container_id
The enter routine opens a terminal and chroot into the environment. The
management tool should also set the container is in "running" state.
3. destroy routine
#qemu_container_destroy container_id
1). exits from chroot environment
2). unmount stuff when not in use
3). clear the qemu-user-arch in binfmt_misc register file (maybe other
containers use it)
4). remove the container info from managment tool
Besides these routines, I would also implement container_list and
container_export routines. The former lists the info/state of containers. The
latter is used to export system images.
Questions:
1). Why integrate qemu-user container with crossdev? Crossdev is a cross
compiler. The qemu-user container not only compiles the heterogeneous programs
but also tests them. I thought if the qemu-user container was good enough, it
could replace the crossdev.
2). "An additional task is to support layered systems so native userspace can
be used to further speed up the process (hybrid chroot)." I don't very
understand the task. Could someone help me and explain the “hybrid chroot”?
Would someone give me some suggestions? Any comments will be much appreciated.
Jing Huang.
