Sam chuanwang66

## java ABQ
the following code is quite helpful to penetrate into the secrete of thread pool:

public class BoundedExecutorService {
	BlockingQueue<Runnable> blockingQueue = new ArrayBlockingQueue<Runnable>(4);
	RejectedExecutionHandler rejectedExecutionHandler = new ThreadPoolExecutor.CallerRunsPolicy();
	private ExecutorService executorService = new ThreadPoolExecutor(2, 2, 0L, TimeUnit.MILLISECONDS,
			blockingQueue, rejectedExecutionHandler);

	public void execute(Runnable command) {
		executorService.submit(command);

## Android's IPC (Binder)
背景文章：看android内核需要看什么——
《Android系统和linux内核的关系详解》
http://blog.sciencenet.cn/blog-618303-626146.html

<Binder IPC Mechanism>
http://www.angryredplanet.com/~hackbod/openbinder/docs/html/BinderIPCMechanism.html

<Android's Binder>
http://lukejin.wordpress.com/2011/03/13/android%E4%B8%AD%E7%9A%84binder/
<技术内幕: Android的IPC机制-Binder>

## gist:60d2387465b1b1a31d3e
git filter-branch --force --index-filter "git rm --cached --ignore-unmatch Project1/Project1.1\ Sample\ Project/output.txt"  --prune-empty --tag-name-filter cat -- --all
git commit --amend -CHEAD
git push origin master

## android binder代码细节剖析（一、binder_init, binder_open, binder_poll, binder_ioctl）
drivers/staging/android/binder.c细节剖析
参见博客《深入分析Android Binder驱动》 http://blog.csdn.net/yangwen123/article/details/9316987
参见系列博客《binder驱动-交互时的传输实现》 http://www.360doc.com/content/12/0103/15/7891085_176883095.shtml

binder驱动不像其他Linux驱动那样有特定的硬件设备与之对应，唯一和硬件沾点边的是它需要对内存操作，不过只是使用内存存储数据罢了。
和其他驱动一样，binder驱动采用了标准的Linux驱动架构，所以才将其纳入驱动之列。

binder_init()
{
	//debugfs_create_dir()

## Linux Debugfs文件系统
  debugfs文件系统是一种用于内核调试的虚拟文件系统，内核开发者通过Debugfs和用户空间交换数据。类似的虚拟文件系统还有procfs和sysfs等，这几种虚拟文件系统都并不是实际存储在硬盘上，而是Linux内核运行起来才建立起来。
  我们知道/proc文件系统关注的是进程信息；/sysfs关注one-value-per-file策略集，而Debugfs文件系统没有如此多限制，可以是任何内核需要输出的信息。
  通常情况下，最常用的内核调试手段是printk。但是printk并不是所有情况都好用，比如打印的数据可能过多，我们真正关心的数据在大量的输出里不是那么一目了然；或者我们在调试时可能需要修改某些内核变量，这种情况下printk就无能为力，而如果为了修改某个值需要重新编译内核或者驱动又过于低效，此时就需要一个临时的文件系统可以把我们需要关心的数据映射到用户空间。在过去，procfs可以实现这个目的，到了2.6时代，新引入的sysfs也同样可以实现。但是无论是procfs还是sysfs，用它们来实现某些debug的需求，似乎偏离了它们创建的本意。比如procfs，其目的是反映进程的状态信息；而sysfs主要用于Linux设备模型。不论是procfs还是sysfs的接口应该保持相对稳定，因为用户态程序很可能会依赖它们。当然，如果我们只是临时借用procfs或者sysfs来作debug之用，在代码发布之前将相关调试代码删除也无不可。但如果相关的调试接口要在相当长一段时间里存在于内核之中，就不太适合放在procfs和sysfs里了。故此，debugfs应运而生。

  1. 安装文件系统：
    Debugfs没有物理设备，默认情况下被挂载在目录/sys/kernel/debug之下，如果发型版里没有自动挂载，可以用如下命令手动完成：
    mount -t debugfs none /sys/kernel/debug
  2. 编程使用：
  	#include <linux/debugfs.h>


## Linux kernel learning
1. How to build Linux Kernel:
http://www.thegeekstuff.com/2013/06/compile-linux-kernel/
http://linux.vbird.org/linux_basic/0540kernel.php
http://haifux.org/lectures/88-sil/kernel-compilation.html

2. How to Create, Compile, Load Linux LKM (Loadable Kernel Modules)

<Linux Loadable Kernel Module HOWTO>
http://www.tldp.org/HOWTO/Module-HOWTO/index.html

## [Linux] Miscellaneous Character Drivers
<Miscellaneous Character Drivers>
http://www.linuxjournal.com/article/2920

## android binder代码细节剖析（二、VMA、接收缓存区管理）
一、VMA
  参见http://www.makelinux.net/books/lkd2/ch14lev1sec2
  Memory areas are represented by a memory area object, which is stored in the vm_area_struct structure and defined in <linux/mm.h>. Memory areas are often called virtual memory areas or VMA's in the kernel.
  The vm_area_struct structure describes a single memory area over a contiguous interval in a given address space. The kernel treats each memory area as a unique memory object. Each memory area shares certain properties, such as permissions and a set of associated operations. In this manner, the single VMA structure can represent multiple types of memory areasfor example, memory-mapped files or the process's user-space stack. This is similar to the object-oriented approach taken by the VFS layer (see Chapter 12, "The Virtual Filesystem"). Here's the structure, with comments added describing each field:

struct vm_area_struct {
        struct mm_struct             *vm_mm;        /* associated mm_struct */
        unsigned long                vm_sta

## android binder代码细节剖析（Binder驱动中的基本结构体）
  参见： http://m.oschina.net/blog/152233
  现代操作系统中，一个进程的地址空间是确定的，地址没有二义性：进程里的一个指针就对应一个内存地址，不可能同事对应到多个地址。但跨进程的情形下，事情就不一样了，不同进程的线性地址空间都是一样的，一个进程里的指针放到另一个进程里，就是完全不同的东西。要实现跨进程的指针，就必须通过操作系统层，只有在系统底层才能将一个进程里的地址映射到另一个进程里的地址，这也就是Binder驱动所做的事情。

  参见这里，非常详细：https://code.google.com/p/sunwayconf/source/browse/trunk/.elisp/dotemacs/org/main.org?r=341
  binder_node stands for a server-side binder stub, while binder_ref stands for a client-side binder proxy.

  1. struct binder_node: 驱动里用“进程”和“进程中的指针”两个参数唯一代表一个Binder实体，Binder驱动中用struct binder_node结构指向Binder实体
struct binder_node {
	int debug_id;
	struct binder_work work;

## python编译时感知运行时实例
为了感知到Python类实例的生成，你可以在运行时去做，但是下面这种方式可以让你在编写代码时候实现这个需求：

class RegistryMetaClass(type):
    registry = []

    def __new__(cls, clsname, bases, attrs):
        newclass = super(RegistryMetaClass, cls).__new__(cls, clsname, bases, attrs)
        RegistryMetaClass.registry.append(newclass())
        return newclass
	the following code is quite helpful to penetrate into the secrete of thread pool:

	public class BoundedExecutorService {
	BlockingQueue<Runnable> blockingQueue = new ArrayBlockingQueue<Runnable>(4);
	RejectedExecutionHandler rejectedExecutionHandler = new ThreadPoolExecutor.CallerRunsPolicy();
	private ExecutorService executorService = new ThreadPoolExecutor(2, 2, 0L, TimeUnit.MILLISECONDS,
	blockingQueue, rejectedExecutionHandler);

	public void execute(Runnable command) {
	executorService.submit(command);
	背景文章：看android内核需要看什么——
	《Android系统和linux内核的关系详解》
	http://blog.sciencenet.cn/blog-618303-626146.html

	<Binder IPC Mechanism>
	http://www.angryredplanet.com/~hackbod/openbinder/docs/html/BinderIPCMechanism.html

	<Android's Binder>
	http://lukejin.wordpress.com/2011/03/13/android%E4%B8%AD%E7%9A%84binder/
	<技术内幕: Android的IPC机制-Binder>
	git filter-branch --force --index-filter "git rm --cached --ignore-unmatch Project1/Project1.1\ Sample\ Project/output.txt" --prune-empty --tag-name-filter cat -- --all
	git commit --amend -CHEAD
	git push origin master
	drivers/staging/android/binder.c细节剖析
	参见博客《深入分析Android Binder驱动》 http://blog.csdn.net/yangwen123/article/details/9316987
	参见系列博客《binder驱动-交互时的传输实现》 http://www.360doc.com/content/12/0103/15/7891085_176883095.shtml

	binder驱动不像其他Linux驱动那样有特定的硬件设备与之对应，唯一和硬件沾点边的是它需要对内存操作，不过只是使用内存存储数据罢了。
	和其他驱动一样，binder驱动采用了标准的Linux驱动架构，所以才将其纳入驱动之列。

	binder_init()
	{
	//debugfs_create_dir()
	debugfs文件系统是一种用于内核调试的虚拟文件系统，内核开发者通过Debugfs和用户空间交换数据。类似的虚拟文件系统还有procfs和sysfs等，这几种虚拟文件系统都并不是实际存储在硬盘上，而是Linux内核运行起来才建立起来。
	我们知道/proc文件系统关注的是进程信息；/sysfs关注one-value-per-file策略集，而Debugfs文件系统没有如此多限制，可以是任何内核需要输出的信息。
	通常情况下，最常用的内核调试手段是printk。但是printk并不是所有情况都好用，比如打印的数据可能过多，我们真正关心的数据在大量的输出里不是那么一目了然；或者我们在调试时可能需要修改某些内核变量，这种情况下printk就无能为力，而如果为了修改某个值需要重新编译内核或者驱动又过于低效，此时就需要一个临时的文件系统可以把我们需要关心的数据映射到用户空间。在过去，procfs可以实现这个目的，到了2.6时代，新引入的sysfs也同样可以实现。但是无论是procfs还是sysfs，用它们来实现某些debug的需求，似乎偏离了它们创建的本意。比如procfs，其目的是反映进程的状态信息；而sysfs主要用于Linux设备模型。不论是procfs还是sysfs的接口应该保持相对稳定，因为用户态程序很可能会依赖它们。当然，如果我们只是临时借用procfs或者sysfs来作debug之用，在代码发布之前将相关调试代码删除也无不可。但如果相关的调试接口要在相当长一段时间里存在于内核之中，就不太适合放在procfs和sysfs里了。故此，debugfs应运而生。

	1. 安装文件系统：
	Debugfs没有物理设备，默认情况下被挂载在目录/sys/kernel/debug之下，如果发型版里没有自动挂载，可以用如下命令手动完成：
	mount -t debugfs none /sys/kernel/debug
	2. 编程使用：
	#include <linux/debugfs.h>
	1. How to build Linux Kernel:
	http://www.thegeekstuff.com/2013/06/compile-linux-kernel/
	http://linux.vbird.org/linux_basic/0540kernel.php
	http://haifux.org/lectures/88-sil/kernel-compilation.html

	2. How to Create, Compile, Load Linux LKM (Loadable Kernel Modules)

	<Linux Loadable Kernel Module HOWTO>
	http://www.tldp.org/HOWTO/Module-HOWTO/index.html
	<Miscellaneous Character Drivers>
	http://www.linuxjournal.com/article/2920
	一、VMA
	参见http://www.makelinux.net/books/lkd2/ch14lev1sec2
	Memory areas are represented by a memory area object, which is stored in the vm_area_struct structure and defined in <linux/mm.h>. Memory areas are often called virtual memory areas or VMA's in the kernel.
	The vm_area_struct structure describes a single memory area over a contiguous interval in a given address space. The kernel treats each memory area as a unique memory object. Each memory area shares certain properties, such as permissions and a set of associated operations. In this manner, the single VMA structure can represent multiple types of memory areasfor example, memory-mapped files or the process's user-space stack. This is similar to the object-oriented approach taken by the VFS layer (see Chapter 12, "The Virtual Filesystem"). Here's the structure, with comments added describing each field:

	struct vm_area_struct {
	struct mm_struct vm_mm; / associated mm_struct */
	unsigned long vm_sta
	参见： http://m.oschina.net/blog/152233
	现代操作系统中，一个进程的地址空间是确定的，地址没有二义性：进程里的一个指针就对应一个内存地址，不可能同事对应到多个地址。但跨进程的情形下，事情就不一样了，不同进程的线性地址空间都是一样的，一个进程里的指针放到另一个进程里，就是完全不同的东西。要实现跨进程的指针，就必须通过操作系统层，只有在系统底层才能将一个进程里的地址映射到另一个进程里的地址，这也就是Binder驱动所做的事情。

	参见这里，非常详细：https://code.google.com/p/sunwayconf/source/browse/trunk/.elisp/dotemacs/org/main.org?r=341
	binder_node stands for a server-side binder stub, while binder_ref stands for a client-side binder proxy.

	1. struct binder_node: 驱动里用“进程”和“进程中的指针”两个参数唯一代表一个Binder实体，Binder驱动中用struct binder_node结构指向Binder实体
	struct binder_node {
	int debug_id;
	struct binder_work work;
	为了感知到Python类实例的生成，你可以在运行时去做，但是下面这种方式可以让你在编写代码时候实现这个需求：

	class RegistryMetaClass(type):
	registry = []

	def __new__(cls, clsname, bases, attrs):
	newclass = super(RegistryMetaClass, cls).__new__(cls, clsname, bases, attrs)
	RegistryMetaClass.registry.append(newclass())
	return newclass