Gentoo Archives: gentoo-soc

From: Jing Huang <jing.huang.pku@×××××.com>
To: gentoo-soc <gentoo-soc@l.g.o>, gentoo-dev <gentoo-dev@l.g.o>
Cc: Luca Barbato <lu_zero@g.o>
Subject: [gentoo-soc] [GSoC2012] Cross Container Support Project
Date: Fri, 23 Mar 2012 12:09:10
1 Hi Everyone,
3 I am a student at Peking University in China. I am very interested in the project of Cross Container Support( I have some ideas about the project. Please help me to examine the thoughts.
4 First, I think downloading stage and portage packets into specified directory each time needs to be impoved( 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.
5 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.
6 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.
7 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:
8 1. create routine
9 # qemu_container_create config_file
10 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:
11 1). If having the arch-img then mount it into chroot directory.
12 2). If not, make a new img file, download stageball&portage, unpack them to the chroot directory.
13 2). modprobe binfmt_misc and register the qemu-user-arch to the binfmt_misc.
14 3). install the static qemu-user into the chroot directory and mount the required directories.
15 4). register this new container to our managment tool. The register info includes container_id, stageball version, stageball arch, chroot directory, etc.
17 2. enter routine
18 #qemu_container_enter container_id
19 The enter routine opens a terminal and chroot into the environment. The management tool should also set the container is in "running" state.
21 3. destroy routine
22 #qemu_container_destroy container_id
23 1). exits from chroot environment
24 2). unmount stuff when not in use
25 3). clear the qemu-user-arch in binfmt_misc register file (maybe other containers use it)
26 4). remove the container info from managment tool
28 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.
30 Questions:
31 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.
32 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”?
34 Would someone give me some suggestions? Any comments will be much appreciated.
36 Jing Huang.


Subject Author
[gentoo-soc] Re: [GSoC2012] Cross Container Support Project Luca Barbato <lu_zero@g.o>