c1b6838e25
In the previous implementation, create a container process by forking the parent process as the container process, and then at the forked child process do much more setting, such as rootfs mounting, drop capabilities and so on, at last exec the container entry cmd to switch into container process. But since the parent is a muti thread process, which would cause a dead lock in the forked child. For example, if one of the parent process's thread do some malloc operation, which would take a mutex lock, and at the same time, the parent forked a child process, since the mutex lock status would be inherited by the child process but there's no chance to release the lock in the child since the child process only has a single thread which would meet a dead lock if it would do some malloc operation. Thus, the new implementation would do exec directly after forked and then do the setting in the exec process. Of course, this requred a data communication between parent and child since the child cannot depends on the shared memory by fork way. Fixes: #166 Fixes: #133 Signed-off-by: fupan.lfp <fupan.lfp@antfin.com> |
||
|---|---|---|
| .github | ||
| ci | ||
| src/agent | ||
| .gitignore | ||
| .travis.yml | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| VERSION | ||
Kata Containers
Welcome to Kata Containers!
The purpose of this repository is to act as a "top level" site for the project. Specifically it is used:
-
To provide a list of the various other Kata Containers repositories, along with a brief explanation of their purpose.
-
To provide a general area for Raising Issues.
Raising issues
This repository is used for raising issues:
-
That might affect multiple code repositories.
-
Where the raiser is unsure which repositories are affected.
Note:
- If an issue affects only a single component, it should be raised in that components repository.
Kata Containers repositories
CI
The CI repository stores the Continuous Integration (CI) system configuration information.
Community
The Community repository is the first place to go if you want to use or contribute to the project.
Code Repositories
Kata Containers-developed components
Agent
The kata-agent runs inside the
virtual machine and sets up the container environment.
KSM throttler
The kata-ksm-throttler
is an optional utility that monitors containers and deduplicates memory to
maximize container density on a host.
Proxy
The kata-proxy is a process that
runs on the host and co-ordinates access to the agent running inside the
virtual machine.
Runtime
The kata-runtime is usually
invoked by a container manager and provides high-level verbs to manage
containers.
Shim
The kata-shim is a process that
runs on the host. It acts as though it is the workload (which actually runs
inside the virtual machine). This shim is required to be compliant with the
expectations of the OCI runtime
specification.
Additional
Hypervisor
The qemu hypervisor is used to
create virtual machines for hosting the containers.
Kernel
The hypervisor uses a Linux* kernel to boot the guest image.
Documentation
The documentation repository hosts documentation common to all code components.
Packaging
We use the packaging repository to create packages for the system components including rootfs and kernel images.
Test code
The tests repository hosts all test code except the unit testing code (which is kept in the same repository as the component it tests).
Utilities
OS builder
The osbuilder tool can create a rootfs and a "mini O/S" image. This image is used by the hypervisor to setup the environment before switching to the workload.
Web content
The www.katacontainers.io repository contains all sources for the https://www.katacontainers.io site.
Credits
Kata Containers uses packagecloud for package hosting.