博客标题

当初接触到Linux的CGroup，觉得很有用，可以做资源的隔离；接触到Namespace，觉得很有用，可以做安全隔离。后来出现了container，觉得很有用，既安全，又可虚拟化。印象中三星的KNOX安全技术就使用了Container技术。只看CGroup和Namespace方的实现源码，但如果不清楚他们的实现目的以及应用场景，很容易陷在code中而忘了初衷。网上描述这三者的文章挺多，以下几

这是n年前写的笔记，是以Arm Android环境为背景所写。今天看vDso时有些关联，就又翻出来瞧了瞧。Elf文件的编译在用户空间，用户代码可以编译为executable、static library，shared library、dynamic binaries。Executable：根据编译脚本executable.mk，会自动将crtbegin_static.S和crtend.S链接进el

signal是一类比较特殊的存在，需要kernel和userspace通力合作才能将signal处理流程走通。Android 平台 Native 代码的崩溃捕获机制及实现对signal的描述比较完整，建议读读。signal处理流程简单的流程描述如下：userspace：利用系统调用sigaction(…)或signal(…)设置感兴趣的signal的属性，包括处理函数、flags等。 已经不鼓励

这也是以前的一篇手记，由于涉及到公司的一些资料，摘录并整理。只是一个简单的流程说明，详细的知识点还请参考相关手册。先来张图热个身。在VT环境下，当中断产生时，有两种场景：在host上下文和guest上下文。 host收到中断后，可以自己处理，也可以将此中断重新路由给Guest；Guest上下文的中断，可以配置为直接路由给Guest，或配置为路由给host。所以需要host和guest间有统一的中断配

Android namespace的实现

Linux Capability的简单介绍和Android Capability的实现

n年前写的一篇PPT，现在看看，还是挺有内容的， 哈。

n年前多核刚刚兴起，说要讲讲SMP，于是就乱诌了一通。

以前看代码，常常为看代码而代码，不常从用户的角度尝试代码所在模块的功能和用途，所以常深陷其中。Kvm很久前就看过代码，但没有认真的看过相关的文档，从而似懂非懂。也曾好奇Kvm和Qemu的关系，但一直不得其解。因为缺少whole picture，所以看代码时只知其然，不知其所以然。

在user利用syscall指令(x86)或svc指令(Arm)发起系统调用后，如果kernel在处理系统调用的过程中被异常打断（如果有信号量pending或被异常唤醒等），此时是retry还是返回？由于是在user的进程上下文中，根据机制和策略分离的原则，kernel一般不会在系统调用处理函数中做retry动作，而是返回user space后再次发起系统调用。