Posts

kernel config 3.2.8 http://0123.blog.163.com/blog/static/4788312011112214258169/ http://www.cnblogs.com/unicode/archive/2010/05/19/1739675.html http://blog.csdn.net/unsigned_/article/details/6123426 http://blog.csdn.net/woshixingaaa/article/details/5982246 1,仔细了解你电脑的硬件型号，越清楚越好切记切记。 2.一定要把SCSI控制器的驱动及与文件系统有关的都编译进内核，而不是模块。 3.把对启动过程没有关系的驱动，一定要编进模块。 4.一定要把你的.config文件复制出来，作为下次重复编译的起点 5.在编译前，一定要保证系统中至少有一个可以正常启动的内核 6.可能在你正确编译完成后，你的一些系统工具不能正常工作，所以不要盲目追新，和util-bin,linux-util,以及模块工具等不能协同工作就悲摧了。 7.一般来说，手动编译的内核启动速度比发行版提供的要快那么一点点，但是，一般的各发行版定制的内核都经过了不同程度的优化，选择自行编译等于放弃了这些优点。除非你清楚你在做什么，否则编译内核只适合喜欢鼓捣学习提高的童鞋。that’s all,good luck! []Prompt for development and/or incomplete code/drivers 对开发中的或者未完成的代码和驱动进行提示, Linux下的很多东西,比如网络设备、文件系统、网络协议等等,它们的功能、稳定性、或者测试等级等等还不能够符合大众化的要求,还处于开发之中。这就是所谓的α版本(阿尔法版本):最初开发版本;接下来的是β版本(beta版本),公开测试版本。如果这是阿尔法版本,那么开发者为了避免收到诸如"为何这东西不工作"的信件的麻烦,常常不会让它发布出去。但是,积极的测试和使用阿尔法版本对软件的开发是非常好的。你只需要明白它未必工作得很好,在某些情况有可能会出问题。汇报详细的出错情况对开发者很有帮助。这个选项同样会让一些老的驱动可用。很多老驱动在后来的内核中已经被代替或者被移除。除非你想要帮助软件的测试,或者开发软件,或者你的机器需要这些特性,否则你可以选N ,那样你会在配置菜单中得到较少的选项。如果你选了Y, 你将会得到更多的阿尔法版本的驱动和代码的配置菜单。 () Cross-compiler tool prefix 交叉编译工具前缀，如果你要使用交叉编译工具的话输入相关前缀。默认不使用。不需要;交叉编译(cross-compile)大致的意思就是在一个平台上为另外一个平台生成代码，也就是说，你在编译时使用的编译器的host和target是不同的，比如你在x86的机器上生成mips的代码。你给本地机器编内核的话，用不到这个。 (ylxy1.2)Local version - append to kernel release 本地版本-附加内核发行版本. 在你的内核版本后面加上一串字符来表示版本。这些字符在你使用 uname -a命令时会显示出来。你在这设置的版本字符将会出现在文件的目录和内容中,如果这些文件调用了内核的版本号。你的字符最多不能超过64位。 [*]Automatically append version information to the version string 自动生成版本信息。这个选项会自动探测你的内核并且生成相应的版本，使之不会和原先的重复。这需要Perl的支持。由于在编译的命令make-kpkg 中我们会加入-append-to-version选项来生成自定义版本，所以这里选N. []Kernel compression mode (Gzip) ((none))Default hostname [*]Support for paging of anonymous memory(swap) 这是使用交换分区或者交换文件来做为虚拟内存的，当然要选上了。 [*]System V IPC 为进程提供通信机制，这将使系统中各进程间有交换信息与保持同步的能力。有些程序只有在选Y的情况下才能运行，所以不用考虑，这里一定要选。 [*] BSD Process Accounting ...

IPC, 进程间通信IPC (InterProcess Communication) 每个进程各自有不同的用户地址空间，任何一个进程的全局变量在另一个进程中都看不到，所以进程之间要交换数据必须通过内核，在内核中开辟一块缓冲区，进程1把数据从用户空间拷到内核缓冲区，进程2再从内核缓冲区把数据读走，内核提供的这种机制称为进程间通信 (IPC，InterProcess Communication) 进程间通信模型 进程间通信的7种方式 匿名管道 命名管道 消息(Message)队列 共享内存 (share memory) 信号量(semaphore) socket (socket) 管道/匿名管道(pipe) 管道是半双工的，数据只能向一个方向流动；需要双方通信时，需要建立起两个管道。 只能用于父子进程或者兄弟进程之间(具有亲缘关系的进程); 单独构成一种独立的文件系统: 管道对于管道两端的进程而言，就是一个文件，但它不是普通的文件，它不属于某种文件系统，而是自立门户，单独构成一种文件系统，并且只存在与内存中。 数据的读出和写入: 一个进程向管道中写的内容被管道另一端的进程读出。写入的内容每次都添加在管道缓冲区的末尾，并且每次都是从缓冲区的头部读出数据。 进程间管道通信模型 管道的实质: 管道的实质是一个内核缓冲区，进程以先进先出的方式从缓冲区存取数据，管道一端的进程顺序的将数据写入缓冲区，另一端的进程则顺序的读出数据。 该缓冲区可以看做是一个循环队列，读和写的位置都是自动增长的，不能随意改变，一个数据只能被读一次，读出来以后在缓冲区就不复存在了。 当缓冲区读空或者写满时，有一定的规则控制相应的读进程或者写进程进入等待队列，当空的缓冲区有新数据写入或者满的缓冲区有数据读出来时，就唤醒等待队列中的进程继续读写。 管道的局限: 管道的主要局限性正体现在它的特点上: 只支持单向数据流； 只能用于具有亲缘关系的进程之间； 没有名字； 管道的缓冲区是有限的 (管道制存在于内存中，在管道创建时，为缓冲区分配一个页面大小) ； 管道所传送的是无格式字节流，这就要求管道的读出方和写入方必须事先约定好数据的格式，比如多少字节算作一个消息 (或命令、或记录) 等等； 命名管道(named pipe) 匿名管道，由于没有名字，只能用于亲缘关系的进程间通信。为了克服这个缺点，提出了有名管道(FIFO)。 有名管道不同于匿名管道之处在于它提供了一个路径名与之关联，以有名管道的文件形式存在于文件系统中，这样，即使与有名管道的创建进程不存在亲缘关系的进程，只要可以访问该路径，就能够彼此通过有名管道相互通信，因此，通过有名管道不相关的进程也能交换数据。值的注意的是，有名管道严格遵循先进先出(first in first out),对匿名管道及有名管道的读总是从开始处返回数据，对它们的写则把数据添加到末尾。它们不支持诸如lseek()等文件定位操作。有名管道的名字存在于文件系统中，内容存放在内存中。 匿名管道和有名管道总结: (1) 管道是特殊类型的文件，在满足先入先出的原则条件下可以进行读写，但不能进行定位读写。 (2) 匿名管道是单向的，只能在有亲缘关系的进程间通信；有名管道以磁盘文件的方式存在，可以实现本机任意两个进程通信。 (3) 无名管道阻塞问题: 无名管道无需显示打开，创建时直接返回文件描述符，在读写时需要确定对方的存在，否则将退出。如果当前进程向无名管道的一端写数据，必须确定另一端有某一进程。如果写入无名管道的数据超过其最大值，写操作将阻塞，如果管道中没有数据，读操作将阻塞，如果管道发现另一端断开，将自动退出。 (4) 有名管道阻塞问题: 有名管道在打开时需要确实对方的存在，否则将阻塞。即以读方式打开某管道，在此之前必须一个进程以写方式打开管道，否则阻塞。此外，可以以读写 (O_RDWR) 模式打开有名管道，即当前进程读，当前进程写，不会阻塞。 延伸阅读: 该博客有匿名管道和有名管道的C语言实践 信号 (Signal) 信号是Linux系统中用于进程间互相通信或者操作的一种机制，信号可以在任何时候发给某一进程，而无需知道该进程的状态。 如果该进程当前并未处于执行状态，则该信号就由内核保存起来，知道该进程回复执行并传递给它为止。 如果一个信号被进程设置为阻塞，则该信号的传递被延迟，直到其阻塞被取消是才被传递给进程。 信号 (Signal) 信号是比较复杂的通信方式,用于通知接受进程有某种事件发生, 除了用于进程间通信外,进程还可以发送信号给进程本身；Linux除了支持Unix早期信号语义函数sigal外,还支持语义符合Posix.1标准的信号函数sigaction (实际上,该函数是基于BSD的,BSD为了实现可靠信号机制,又能够统一对外接口,用sigaction函数重新实现了signal函数) ...

sysstat system performance tools for Linux The sysstat package contains the following system performance tools: sar: collects and reports system activity information; iostat: reports CPU utilization and disk I/O statistics; mpstat: reports global and per-processor statistics; pidstat: reports statistics for Linux tasks (processes); sadf: displays data collected by sar in various formats. The statistics reported by sar deal with I/O transfer rates, paging activity, process-related activities, interrupts, network activity, memory and swap space utilization, CPU ...

eBPF eBPF 的用处 有了 eBPF，无需修改内核，也不用加载内核模块，程序员也能在内核中执行自定义的字节码。eBPF 和内核紧密联系，下面先介绍一些相关的基本概念。 Linux 系统分为内核空间和用户空间。内核空间是操作系统的核心，对所有硬件都具备不受限制的完整的访问能力，例如内存、存储以及 CPU 等。内核既然具备了这样的超级权限，势必需要严加保护，仅允许运行最可靠的代码。而用户空间运行的就是非内核的进程——例如 I/O、文件系统等。这些进程仅能通过内核开放的系统调用，对硬件进行有限的访问。换句话说，用户空间的程序一定要经过内核空间的过滤。 系统调用接口能够满足绝大多数需要，开发者在面对新的硬件、文件系统、网络协议甚至自定义的系统调用时，还是需要更多的弹性的。在不修改内核源码的情况下，用户代码要直接访问硬件怎么办呢？可以使用 Linux 内核模块 (LKM）。用户空间一般是需要通过系统调用来访问内核空间，而 LKM 是直接加载到内核的，是内核的一部分。LKM 最有价值的特点之一，就是可以在运行时加载，不用编译内核也不用重启机器。 what is ebpf 1 图 1：LKM 的动态加载和卸载 LKM 非常有用，但是也引入了很多风险。内核和用户空间不同，要进行不同的安全考量。内核空间是为了操作系统内核这样的特权代码准备的。系统调用连接了内核和用户空间，让用户空间能够对硬件进行合适的操作。换个说法，LKM 是能够让内核崩溃的。模块和内核的紧密关系，使得安全和升级成本直线升高。 eBPF 是什么 eBPF 是一个用于访问 Linux 内核服务和硬件的新方法。这一新技术已经用于网络、出错、跟踪以及防火墙等方面。 dtrace 是一个 Solaris 和 BSD 操作系统上的动态跟踪工具，eBPF 受到 dtrace 的启发，原意是设计一个更好的 Linux 跟踪工具。跟 dtrace 不同的是，Linux 无法获取运行中系统的鸟瞰视图，它被系统调用、库调用以及函数所限制。一小撮工程师在 Berkeley Packet Filter (BPF）基础之上，构建一个内核虚拟机级别的包过滤机制，提供了类似 dtrace 的功能。2014 年第一个版本适配了 Linux 3.18，提供的功能相对较少。要使用完整的 eBPF，需要 Linux 4.4 或以上。 what is ebpf 2 上图对 eBPF 架构进行了一个简单的展示。eBPF 程序需要满足一系列的需求，才能被加载到内核。Verifier 中有一万多行代码用来对 eBPF 程序进行检查。Verifier 会遍历对 eBPF 程序在内核中可能的执行路径进行遍历，确保程序能够在不出现导致内核锁定的循环的情况下运行完成。除此之外还有其它必须满足的检查，例如有效的寄存器状态、程序大小以及越界等。安全控制方面，eBPF 和 LKM 是颇有差异的。 ...

System.map、vmlinuz、initrd.img vmlinuz 1.vmlinuz是可引导的、压缩的内核。“vm"代表"Virtual Memory”。Linux 支持虚拟内存，不像老的操作系统比如DOS有640KB内存的限制。Linux能够使用硬盘空间作为虚拟内存，因此得名"vm"。vmlinuz是可执行 的Linux内核，它位于/boot/vmlinuz，它一般是一个软链接，比如图中是vmlinuz-2.4.7-10的软链接。 vmlinuz的建立有两种方式。一是编译内核时通过"make zImage"创建，然后通过:“cp /usr/src/linux-2.4/arch/i386/linux/boot/zImage/boot/vmlinuz"产生。zImage适用于 小内核的情况，它的存在是为了向后的兼容性。 2.是内核编译时通过命令make bzImage创建，然后通过:“cp/usr/src/linux-2.4/arch/i386/linux/boot/bzImage /boot/vmlinuz"产生。bzImage是压缩的内核映像，需要注意，bzImage不是用bzip2压缩的，bzImage中的bz容易引起误解，bz表示"big zImage”。 bzImage中的b是"big"意思。 zImage(vmlinuz)和bzImage(vmlinuz)都是用gzip压缩的。它们不仅是一个压缩文件，而且在这两个文件的开头部分内嵌有 gzip解压缩代码。所以你不能用gunzip 或 gzip –dc解包vmlinuz。内核文件中包含一个微型的gzip用于解压缩内核并引导它。两者的不同之处在于，老的zImage解压缩内核到低端内存(第一 个640K)， bzImage解压缩内核到高端内存(1M以上)。如果内核比较小，那么可以采用zImage或bzImage之一，两种方式引导的系统运行时是相同的。 大的内核采用bzImage，不能采用zImage。vmlinux是未压缩的内核，vmlinuz是vmlinux的压缩文件。 二、initrd-x.x.x.img initrd是"initial ramdisk"的简写。initrd一般被用来临时的引导硬件到实际内核vmlinuz能够接管并继续引导的状态。图中的initrd-2.4.7- 10.img主要是用于加载ext3等文件系统及scsi设备的驱动。比如，使用的是scsi硬盘，而内核vmlinuz中并没有这个scsi硬件的驱 动，那么在装入scsi模块之前，内核不能加载根文件系统，但 scsi模块存储在根文件系统的/lib/modules下。为了解决这个问题，可以引导一个能够读实际内核的initrd内核并用initrd修正 scsi引导问题。initrd-2.6.20-1.img是用gzip压缩的文件，initrd实现加载一些模块和安装文件系统等功能。 initrd映象文件是使用mkinitrd创建的。mkinitrd实用程序能够创建initrd映象文件。这个命令是RedHat专有的。其它 Linux发行版或许有相应的命令。这是个很方便的实用程序。具体情况请看帮助:man mkinitrd下面的命令创建initrd映象文件。 initrd是linux在系统引导过程中使用的一个临时的根文件系统，用来支持两阶段的引导过程。 直白一点，initrd就是一个带有根文件系统的虚拟RAM盘，里面包含了根目录'/'，以及其他的目录，比如: bin，dev，proc，sbin，sys等linux启动时必须的目录，以及在bin目录下加入了一下必须的可执行命令。 PC或者服务器linux内核使用这个initrd来挂载真正的根文件系统，然后将此initrd从内存中 卸掉，这种情况下initrd其实就是一个过渡使用的东西。 在现在的许多简单嵌入式linux中一般是不卸载这个initrd的，而是直接将其作为根文件系统使用，在这之前就需要把所需要的程序，命令还有其它文件 都安装到这个文件系统中。其实现在的大多数嵌入式系统也是有自己的磁盘的，所以，initrd在现在大多数的嵌入式系统中也和一般的linux中的作用一 样只是起过渡使用。 Initrd的引导过程: '第二阶段引导程序'，常用的是grub将内核解压缩并拷贝到内存中，然后内 核接管了CPU开始执行，然后内核调用init()函数，注意，此init函数并不是后来的init进程！！！然后内核调用函数 initrd_load()来在内存中加载initrd根文件系统。Initrd_load()函数又调用了一些其他的函数来为RAM磁盘分配空间，并计 算CRC等操作。然后对RAM磁盘进行解压，并将其加载到内存中。现在，内存中就有了initrd的映象。 然后内核会调用mount_root()函数来创建真正的根分区文件系统，然后调用sys_mount()函数来加载真正的根文件系统，然后chdir到这个真正的根文件系统中。 最后，init函数调用run_init_process函数，利用execve来启动init进程，从而进入init的运行过程。 三、System.map 内核符号映射表，顾名思义就是将内核中的符号 (也就是内核中的函数) 和它的地址能联系起来的一个列表。是所有符号及其对应地址的一个列表。之所以这样就使 为了用户编程方便，直接使用函数符号就可以了，而不用去记要使用函数的地址。当你编译一个新内核时，原来的System.map中的符号信息就不正确 了。随着每次内核的编译，就会产生一个新的 System.map文件，并且需要用该文件取代原来的文件 System.map是一个特定内核的内核符号表。它是你当前运行的内核的System.map的链接。 内核符号表是怎么创建的呢? System.map是由"nm vmlinux"产生并且不相关的符号被滤出。 下面是System.map文件的一部分: c0100000 A _text c0100000 t startup_32 c01000a5 t checkCPUtype c0100133 t is486 c0100142 t is386 c010018c t L6 c010018e t ready c010018f t check_x87 c01001b6 t setup_idt c01001d3 t rp_sidt c01001e0 T stack_start c01001e8 t int_msg c01001fc t ignore_int c010021e T idt_descr c0100224 T cpu_gdt_descr c0101000 T swapper_pg_dir c0102000 T pg0 c0103000 T pg1 c0104000 T empty_zero_page c0105000 T _stext 在进行程序设计时，会命名一些变量名或函数名之类的符号。Linux内核是一个很复杂的代码块，有许许多多的全局符号。 Linux内核不使用符号名，而是通过变量或函数的地址来识别变量或函数名。比如不是使用size_t BytesRead这样的符号，而是像c0343f20这样引用这个变量。 对于使用计算机的人来说，更喜欢使用那些像size_t BytesRead这样的名字，而不喜欢像c0343f20这样的名字。内核主要是用c写的，所以编译器/连接器允许我们编码时使用符号名，当内核运行时使用地址。 然而，在有的情况下，我们需要知道符号的地址，或者需要知道地址对应的符号。这由符号表来完成，符号表是所有符号连同它们的地址的列表。上图就是一个内核符号表，由上图可知变量名checkCPUtype在内核地址c01000a5。 Linux 符号表使用到2个文件: /proc/ksyms System.map ...

linux 内核, kernel kernel-devel和kernel-headers都是Linux内核开发和编译过程中需要的软件包，它们包含的内容有一定的区别。 kernel-headers是Linux内核头文件的软件包，它包含了编译内核模块所需的头文件和接口定义，但是不包含内核模块的源代码。这些头文件包括了Linux内核的各种数据结构、系统调用和其他接口的声明，编译内核模块时需要这些头文件来编译并链接内核模块。 kernel-devel则是Linux内核开发包，它不仅包含了内核头文件，还包含了编译内核模块所需的各种库文件、编译器和调试工具等。它还包含了内核模块的源代码，可以让开发人员对内核进行修改和定制。 kernel doc https://www.kernel.org/doc/html/latest/ linux内核版本的分类 Linux内核版本有两种: 稳定版和开发版 ，Linux内核版本号由3组数字组成: 第一个组数字.第二组数字.第三组数字 第一个组数字: 目前发布的内核主版本。 第二个组数字: 偶数表示稳定版本；奇数表示开发中版本。 第三个组数字: 错误修补的次数。 例1: 2.6.18-128.ELsmp , 第一个组数字: 2 , 主版本号 第二个组数字: 6 , 次版本号，表示稳定版本(因为有偶数) 第三个组数字 18 , 修订版本号 ， 表示修改的次数，头两个数字合在一齐可以描述内核系列。如稳定版的2.6.0，它是2.6版内核系列。128: 表示这个当前版本的第128次微调patch ， 而ELsmp指出了当前内核是为ELsmp特别调校的 EL : Enterprise Linux ； smp : 表示支持多处理器 ， 表示该内核版本支持多处理器 linux内核下里的ELsmp与EL与smp 在linux下ELsmp指出了当前内核是为ELsmp特别调校的 EL : Enterprise Linux ； smp : 表示支持多处理器 ， 表示该内核版本支持多处理器 例2:Red Hat Linux开机的时候，GRUB的启动菜单会有两个选项，分别是 Red Hat Enterprise Linux ES (版本号.ELsmp) Red Hat Enterprise Linux ES-up (版本号.EL) 其实这个就是系统开机时由GRUB引导启动 － 单处理器与对称多处理器启动核心文件的区别。 Red Hat Enterprise Linux ES (版本号.ELsmp) multiple processor (symmetric multiprocessing ) Red Hat Enterprise Linux ES-up (版本号.EL) uniprocessor ...

gz,bz2,xz三种压缩格式的 OpenBSD CVS库容量对比 gz,bz2,xz三种压缩格式的 OpenBSD CVS库容量对比 压缩gz格式速度最快，也是OpenBSD的常用格式，压缩bz2格式时间稍长一些，但似乎在好机器上还可以接受，xz格式的压缩效果确实不错，cvs.tar是打包的全部OpenBSD CVS库，原本大小有5G多，经过xz压缩后只有700多M，不得不说压缩算法确实强悍，不过压缩时间太长——在我的1300MHz主频的老机器上，将5G多的cvs打包文件压缩成xz格式用了两个小时左右，看来这种格式最好不作为日常采用的格式，但是如果作为放在服务器上供长期、大量下载的资源，使用这种压缩格式来进行压缩和解压尚可理解。 代码: ls -la total 14202000 drwxr-xr-x 3 root wheel 512 Mar 25 21:18 . drwxr-xr-x 15 root wheel 512 Mar 25 16:35 .. drwxr-xr-x 10 root wheel 512 Mar 25 17:49 cvs -rw-r–r– 1 root wheel 387 Mar 25 16:40 cvs-supfile -rw-r–r– 1 root wheel 5208381440 Mar 25 21:18 cvs.tar -rw-r–r– 1 root wheel 898476333 Mar 25 21:03 cvs.tar.bz2 -rw-r–r– 1 root wheel 1162675369 Mar 25 21:13 cvs.tar.gz ...

GCC GCC (GNU Compiler Collection ) ，GCC是一系列编译器的集合, 是Linux操作系统的核心组件之一。是一套由 GNU 开发的编程语言编译器。它是一套GNU编译器套装以 GPL 及 LGPL 许可证所发行的自由软件，也是 GNU计划的关键部分，亦是自由的类Unix及苹果电脑 Mac OS X 操作系统的标准编译器。GCC 原名为 GNU C 语言编译器，因为它原本只能处理 C语言。GCC 很快地扩展，变得可处理 C++。之后也变得可处理 Fortran、Pascal、Objective-C、Java, 以及 Ada与其他语言。 GCC最初名为GNU C Compiler，当时它只是一款C语言的编译器，不过随着后续迭代，它支持C++、Fortran、Go等语言，GCC也因此成为一个编译器集合。GCC有以下特点： GCC支持的编程语言多。比如，g++ 是 C++ 编译器，gfortran是 Fortran 编译器。 GCC支持的硬件全。GCC可以将源代码编译成x86_64、ARM、PowerPC等硬件架构平台的可执行文件。 GCC支持众多业界标准。GCC能很快支持最新的C++标准，GCC支持OpenMP、OpenACC。 虽然编译器并非只有GCC一种，macOS上有Clang，Windows上有MSVC，但GCC的这些特点让它从众多编译器间脱颖而出，很多开源软件会选择GCC完成编译工作。 刚才提到，软件构建的过程比较复杂，GCC的一些“兄弟”工具提供了很多支持功能： GNU Make：一款自动化编译和构建工具，多文件、多模块的大型软件工程经常需要使用GNU Make。 GDB：GNU Debugger，用于调试。 GNU Binutils：一组二进制工具集，包括链接器ld、汇编器as等，GNU Bintuils可以和GCC、GNU Make一起完成构建过程。我们将在下文使用这些工具。 综上，GCC在Linux操作系统占有举足轻重的地位。 预处理 使用预处理器cpp工具进行预处理。注意，这里的cpp是C Preprocessor的缩写，并不是C-plus-plus的意思。 cpp hello.c -o hello.i 预编译主要处理源代码中以#开始的预编译指令，主要处理规则如下： 处理#include 预编译指令，将被包含的文件插入到该预编译指令的位置。这是一个递归的过程，如果被包含的文件还包含了其他文件，会递归地完成这个过程。 处理条件预编译指令，比如#if、#ifdef、#elif、#else、#endif。 删除#define，展开所有宏定义。 添加行号和文件名标识，以便于在编译过程中产生编译错误或者调试时都能够生成行号信息。 编译 编译的过程主要是进行词法分析、语法分析、语义分析，这背后涉及编译原理等一些内容。这里只进行编译，不汇编，可以生成硬件平台相关的汇编语言。 $ gcc -S hello.i -o hello.s gcc其实已经做了封装，背后是使用一个名为cc1的工具，cc1并没有放在默认的路径里。Ubuntu 16.04系统上，cc1位于：/usr/lib/gcc/x86_64-linux-gnu/5.4.0/cc1： ...

VFS Linux 采用 Virtual Filesystem（VFS）的概念，通过内核在物理存储介质上的文件系统和用户之间建立起一个虚拟文件系统的软件抽象层，使得 Linux 能够支持目前绝大多数的文件系统，不论它是 windows、unix 还是其他一些系统的文件系统，都可以挂载在 Linux 上供用户使用。 VFS 在 Linux 中是一个处理所有 unix 文件系统调用的软件层，同时给不同类型的文件系统提供一个统一的接口。VFS 支持以下归类的三种类型的文件系统： 磁盘文件系统，存储在本地磁盘、U盘、CD等的文件系统，它包含各种不同的文件系统格式，比如 windows NTFS、VFAT，BSD 的 UFS，CD的 CD-ROM 等 网络文件系统，它们存储在网络中的其他主机上，通过网络进行访问，例如 NFS 特殊文件系统，例如 /proc、sysfs 等 VFS 背后的思想就是建立一个通用的文件模型，使得它能兼容所有的文件系统，这个通用的文件模型是以 Linux 的文件系统 EXT 系列为模版构建的。每个特定的文件系统都需要将它物理结构转换为通用文件模型。例如，通用文件模型中，所有的目录都是文件，它包含文件和目录；而在其他的文件类型中，比如 FAT，它的目录就不属于文件，这时，内核就会在内存中生成这样的目录文件，以满足通用文件模型的要求。同时，VFS 在处理实际的文件操作时，通过指针指向特定文件的操作函数。可以认为通用文件模型是面向对象的设计，它实现了几个文件通用模型的对象定义，而具体的文件系统就是对这些对象的实例化。通用文件模型包含下面几个对象： superblock 存储挂载的文件系统的相关信息 inode 存储一个特定文件的相关信息 file 存储进程中一个打开的文件的交互相关的信息 dentry 存储目录和文件的链接信息 https://wushifublog.com/2020/05/22/%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3Linux%E5%86%85%E6%A0%B8%E2%80%94%E2%80%94VFS/ VFS并不是一种实际的文件系统，它只存在于内存中，不存在任何外存空间，VFS在系统启动时建立，在系统关闭时消亡。 VFS由超级块、inode、dentry、vfsmount等结构来组成。

gitignore 忽略子目录下所有某后缀的文件 **/*.iml 具体使用请看 man gitignore 一般某个项目dev过程中都会产生一些中间文件，这些文件是我们不想要追踪的。 git中可以使用.gitignore文件来忽略这些文件。 在需要的目录下面 添加 .gitignore文件 文件中每一行表示需要忽略的文件的正则表达式。 cat .gitignore .metadata # ignore obj and lib file *.[oa] 当前的目录情况 $ls -al total 24 drwxr-xr-x 4 root root 4096 2010-12-11 12:44 . drwx– 51 root root 4096 2010-12-11 12:44 .. drwxr-xr-x 8 root root 4096 2010-12-11 12:44 .git -rw-r-r- 1 root root 39 2010-12-11 12:44 .gitignore drwxr-xr-x 3 root root 4096 2010-08-19 20:01 .metadata -rw-r-r- 1 root root 52 2010-12-11 12:41 test.txt ...

overflow, hidden 核心提示: overflow:hidden这个CSS样式是大家常用到的CSS样式，但是大多数人对这个样式的理解仅仅局限于隐藏溢出，而对于清除浮动这个含义不是很了解。 overflow:hidden这个CSS样式是大家常用到的CSS样式，但是大多数人对这个样式的理解仅仅局限于隐藏溢出，而对于清除浮动这个含义不是很了解。 一提到清除浮动，我们就会想到另外一个CSS样式: clear:both，我相信对于这个属性的理解大家都不成问题的。但是对于"浮动"这个词到底包含什么样的含义呢？我们下面来详细的阐述一下。 这是一个常用的div写法，下面我们来书写样式。大家可以在DMX中自己做试验 #wai{ width:500px; background:#000; height:500px;} #nei { float:left; width:600px; height:600px; background:red;} 可以看到，我给nei这个id加了一个浮动，我们常规的理解是，我们允许nei这个id的div的右边出现其他的内容，只要它的宽度不超过wai这个div和nei这个div的剩余值。 如果div wai中还包含其他的div，我不允许它出现在nei的右侧，我们则用样式clear:both指定这个div，不允许它浮动在nei右侧。 这些在ie6里面是正确的。但是在火狐或者其他浏览器里面，我们发现问题并非如此简单。我们发现，当nei这个div的宽度和高度都大于wai这个div的时候，wai并没有被内撑开而是依旧显示为我们指定的宽高。在我的例子中，都是500。 这个时候我不理解了，我搜索了很多的资料，但是都没能理解这是为什么，直到看到别人在类似的情况下给wai这个div加了一个overflow:hidden这个属性解决了这个问题。 我们直到overflow:hidden这个属性的作用是隐藏溢出，给wai加上这个属性后，我们的nei的宽高自动的被隐藏掉了。另外，我们再做一个试验，将wai这个div的高度值删除后，我们发现，wai的高度自动的被nei这个div的高度值给撑开了。 说到这里，我们再来理解一下"浮动"这个词的含义。我们原先的理解是，在一个平面上的浮动，但是通过这个试验，我们发现，这不仅仅是一个平面上的浮动，而是一个立体的浮动！ 也就是说，当nei这个div加上浮动这个属性的时候，在显示器的侧面，它已经脱离了wai这个div，也就是说，此时的nei的宽高是多少，对于已经脱离了的wai来说，都是不起作用的。打个形象的比喻就是当JJ脱离BB的时候，JJ的大小对于BB是没有撑开的作用的 (有点少儿不宜的感觉-_-|||) OK，当我们全面的理解了浮动这个词的含义的时候，我们就理解overflow:hidden这个属性中的解释，清除浮动是什么意思了。也就是说，当我们给wai这个div加上overflow:hidden这个属性的时候，其中的nei等等带浮动属性的div的在这个立体的浮动已经被清除了，就好比JJ又进入了BB内，JJ的大小自然又会影响到BB的大小。 这就是overflow:hidden这个属性清除浮动的准确含义。 当我们没有给wai这个div设置高度的时候，nei这个div的高度，就会撑开wai这个div，而在另一个方面，我们要注意到的是，当我们给wai这个div加上一个高度值，那么无论nei这个div的高度是多少，wai这个高度都是我们设定的值。而当nei的高度超过wai的高度的时候，超出的部分就会被隐藏。这就是隐藏溢出的含义！ 我相信，通过我的这些文字，大家对overflow:hidden这个属性有了全新的认识。希望大家和我一样，在div+css学习中能够不断的进步！ (PS: 本人是div+css的初学者，请高手不要嘲笑。困惑这个属性已经很久，网上的资料大多不怎么理想，因此才写这些文字献丑。本文为地方网络工作室原创。转载请保留本工作室链接，文章首发: http://www.difangla.com/Html/jishu/css/88140.html)

css垂直居中 单行内容的居中 只考虑单行是最简单的，无论是否给容器固定高度，只要给容器设置 line-height 和 height，并使两值相等，再加上 over-flow: hidden 就可以了 [css] .middle-demo-1{ height: 4em; line-height: 4em; overflow: hidden; } [/css] 优点: 同时支持块级和内联极元素 支持所有浏览器 缺点: 只能显示一行 IE中不支持等的居中 要注意的是: 使用相对高度定义你的 height 和 line-height 不想毁了你的布局的话，overflow: hidden 一定要加上。

关系型数据库 VS 非关系型数据库 关系型数据库(Relational database) VS 非关系型数据库 一、关系型数据库？ 1.概念 关系型数据库是指采用了关系模型来组织数据的数据库。简单来说，关系模式就是二维表格模型。 主要代表：SQL Server，Oracle,Mysql,PostgreSQL。 2.优点 (1）.容易理解，二维表的结构非常贴近现实世界，二维表格，容易理解。 (2）使用方便，通用的sql语句使得操作关系型数据库非常方便。 (3）易于维护，数据库的ACID属性，大大降低了数据冗余和数据不一致的概率。 3.瓶颈 (1 )海量数据的读写效率。 对于网站的并发量高，往往达到每秒上万次的请求，对于传统关系型数据库来说，硬盘I/o是一个很大的挑战。 (2) 高扩展性和可用性。 在基于web的结构中，数据库是最难以横向拓展的，当一个应用系统的用户量和访问量与日俱增的时候，数据库没有办法像web Server那样简单的通过添加更多的硬件和服务节点来拓展性能和负载能力。 传统数据库操作涉及事物机制，每次写入操作需要进行undo、redo操作，然后将redo操作记录到日志文件，有事物开销,不适合写多读少的场景. 二、从关系型到非关系型 关系型数据库的最大优点就是事务的一致性，这个特性，使得关系型数据库中可以适用于一切要求一致性比较高的系统中。比如：银行系统。 但是在网页应用中，对这种一致性的要求不是那么的严格，允许有一定的时间间隔，所以关系型数据库这个特点不是那么的重要了。相反，关系型数据库为了维护一致性所付出的巨大代价就是读写性能比较差。而像微博、facebook这类应用，对于并发读写能力要求极高，关系型数据库已经无法应付。所以必须用一种新的数据结构存储来替代关系型数据库。所以非关系型数据库应用而生。 三、非关系型 1.概念 NoSQL非关系型数据库，主要指那些非关系型的、分布式的，且一般不保证ACID的数据存储系统，主要代表MongoDB，Redis、CouchDB。 NoSQL提出了另一种理念，以键值来存储，且结构不稳定，每一个元组都可以有不一样的字段，这种就不会局限于固定的结构，可以减少一些时间和空间的开销。使用这种方式，为了获取用户的不同信息，不需要像关系型数据库中，需要进行多表查询。仅仅需要根据key来取出对应的value值即可。 2.分类 非关系数据库大部分是开源的，实现比较简单，大都是针对一些特性的应用需求出现的。根据结构化方法和应用场景的不同，分为以下几类。 (1）面向高性能并发读写的key-value数据库 主要特点是具有极高的并发读写性能，例如Redis、Tokyo Cabint等。 (2）面向海量数据访问的面向文档数据库 特点是，可以在海量的数据库快速的查询数据。例如MongoDB以及CouchDB. (3）面向可拓展的分布式数据库 解决的主要问题是传统数据库的扩展性上的缺陷。 3.缺点 但是由于Nosql约束少，所以也不能够像sql那样提供where字段属性的查询。因此适合存储较为简单的数据。有一些不能够持久化数据，所以需要和关系型数据库结合。 四、对比 1.存储上？ Sql通常以数据库表的形式存储，例如存储用户信息，SQL中增加外部关系的话，需要在原表中增加一个外键，来关联外部数据表。如下： NoSql采用key-value的形式存储 2.事务？ SQL中如果多张表需要同批次被更新，即如果其中一张表跟新失败的话，其他表也不会更新成功。这种场景可以通过事务来控制，可以在所有命令完成之后，再统一提交事务。在Nosql中没有事务这个概念，每一个数据集都是原子级别的。 3.数据表 VS 数据集 关系型是表格型的，存储在数据表的行和列中。彼此关联，容易提取。而非关系型是大块存储在一起。 4.预定义结构 VS 动态结构 在sql中，必须定义好地段和表结构之后，才能够添加数据，例如定义表的主键、索引、外键等。表结构可以在定义之后更新，但是如果有比较大的结构变更，就会变的比较复杂。 在Nosql数据库中，数据可以在任何时候任何地方添加。不需要预先定义。 5.存储规范 VS 存储代码 关系型数据库为了规范性，把数据分配成为最小的逻辑表来存储避免重复，获得精简的空间利用。但是多个表之间的关系限制，多表管理就有点复杂。 当然精简的存储可以节约宝贵的数据存储，但是现在随着社会的发展，磁盘上付出的代价是微不足知道的。 非关系型是平面数据集合中，数据经常可以重复，单个数据库很少被分开，而是存储成为一个整体，这种整块读取数据效率更高。 6.纵向拓展 VS 横向拓展 ...

Foldit Foldit就是这样一个程序，它打算用人类的解谜思维来代替计算机算法中的一部分决策，把确定蛋白质的最佳三维形状设计成一个游戏，使得人们在游戏过程中也能对生物科学做出贡献。在这个游戏中你可以不断调整蛋白质的三维形状，上传最高分和所得的三维体，参与世界排名，并且还能与游戏参与者进行即时聊天。 Rosetta@home是一个基于伯克利开放式网络计算平台 (BOINC) 的分布式计算项目。该项目由华盛顿大学贝克实验室开发和维护，用于蛋白质结构预测、蛋白质-蛋白质对接和蛋白质设计的研究。截至2009年12月9日，全球共有8.2万台计算机是这一项目的活跃志愿者，平均执行速度达99万亿FLOPS。Rosetta@Home还开发了一款电子游戏Foldit，目的是通过众包 (crowdsourcing) 途径来实现上述研究目标。尽管这个项目很大程度上侧重于进行提高蛋白质组学方法的精确性和稳固性的基础研究，它也进行一些关于艾滋病、疟疾、癌症、阿兹海默病以及其他疾病的病理学的应用研究。 与其他BOINC项目一样，Rosetta@home使用志愿者的计算机中空闲的进程资源来执行单独的单元计算。计算结果会被发送到项目的中央服务器，经验证后存入数据库中。这个项目是跨平台的，支持多种不同的软件和硬件环境。用户可通过Rosetta@home的屏幕保护程序观看正在自己计算机上进行的蛋白质结构预测的情况。 除了疾病相关研究，Rosetta@home网络还是结构生物信息学中新方法的一个测试框架。这些新方法经Rosetta@home庞大且多样的用户群体使用后，若运行效果稳定，将会被用于其他基于Rosetta的应用程序，例如RosettaDock和人类蛋白质组折叠项目。新方法测试中的两个重要项目是蛋白质结构预测技术的关键测试 (CASP) 和交互作用预测的关键测试 (CAPRI) 。这两项测试实验分别用于评估蛋白质结构预测和蛋白质-蛋白质对接预测的最前沿技术。Rosetta@home稳居最重要的对接预测器之一，并且是现有最好的蛋白质三级结构预测器之一。

HTML5 中 div section article 的区别 div HTML Spec: “The div element has no special meaning at all.” 这个标签是我们见得最多、用得最多的一个标签。本身没有任何语义，用作布局以及样式化或脚本的钩子(hook)。 section HTML Spec: “The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.” 与 div 的无语义相对，简单地说 section 就是带有语义的 div 了，但是千万不要觉得真得这么简单。section 表示一段专题性的内容，一般会带有标题。看到这里，我们也许会想到，那么一篇博客文章，或者一条单独的评论岂不是正好可以用 section 吗？接着看: “Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the elemen.” ...

写放大 Write Amplification “写放大”(Write Amplification)在存储系统中是很常见的。但是，即使都是在存储系统中，“写放大”也有很多种，各种的写放大原理并不是很一样。下边根据自己的理解，进行了下总结，如有问题，恳请指正。 读写单元较大导致的写放大 在文件系统中，读写单元固定，比如都是4K，这样，如果write函数写的数据小于4K，则要先把整块读入，再修改，再把新的4K整体写入 (O_DIRECT情况除外）。这个过程可以称为 RMW (Read-Modify-Write)，这就是File System的写放大问题。[1][2][5] (注意：Read-Modify-Write被更广泛地用在原子指令[3]和RAID[4]中。） 再如，在DBMS等应用层存储系统中，同样存在自己管理的读写单元，如MySQL的默认读写单元称为页，默认是16KB，所以一次读写只能以页的单位进行，这时，小于页的数据读写同样会带来整页的读写，进而造成了“写放大”，道理和文件系统是一样的。 RAID中的Read-Modify-Write造成的写放大 如前段所述，RAID中更新一个块，需要额外读原始块、校验块，额外写校验块，所以多了两个读，一个写，也称为Read-Modify-Write[4]。 这是由于校验块必须更新，且根据异或运算的可逆性，新校验块=新数据块^旧校验块^旧数据块。 SSD中闪存特性造成的写放大 在SSD中，一个block可以分为多个page，在读的时候，可以以page为单位，但是写的时候，只能以block为单位。因此写的单元比较大。在上层 (比如文件系统）读写单元相同的情况下，同样是读写1个page的大小，读的话直接读就行，写的话却需要先把与要写page同一个block的数据全复制一遍，加上修改的page后，再一起写入block。写入的数据量远比实际的大，这就是SSD的写放大问题。 现在 SSD 逐渐成为主流存储，compaction 带来的写放大问题显得越来越严重： SSD 顺序读写性能比随机读写性能好一些，但是差距并没有 HDD 那么大。所以，顺序写相比随机写带来的好处，能不能抵消写放大带来的开销，这是个问题。 SSD 的使用寿命和其写入量有关，写放大太严重会大大缩短 SSD 的使用寿命。因为 SSD 不支持覆盖写，必须先擦除 (erase）再写入。而每个 SSD block (block 是 SSD 擦除操作的基本单位） 的平均擦除次数是有限的。 存储系统一致性机制造成的同步写放大 在存储系统的很多层次中，都有保证系统crash consistency (一致性）的设计。因此，不管是应用层的存储系统 (如DBMS、KV-store）、虚拟化层中的镜像管理、系统层的文件系统，甚至是硬件层的SSD FTL[7]，都要通过强制同步各种元数据的写入顺序，或者利用redo log的思想，用journaling、log-structured或copy-on-write等策略保证元数据写入目的位置生效前先完整地生成日志，来保证系统崩溃或断电时，元数据之间是一致。但是，如果多层存储系统重叠，由于一致性机制导致同步次数增加就会层层放大。 比如，运行在x86虚拟机中的levelDB，其一次更新操作就会 (1）最终导致levelDB写log文件和写数据两次同步写，这两次写就又会 (2）导致2次的Guest文件系统log写和2次Guest文件系统数据写，一共4次同步写，这4次写又会导致 (3）虚拟化镜像管理层的4 x N次写 (N取决于镜像为保证元数据crash consistency的同步次数，若是qcow2格式，N可能有5次之多[6]），最后导致 (4）Host文件系统的4 x N x 2 = 8 x N次同步写。当然这是一种比较极端的情况，但实际应用中也应该存在。 基于LSM树的KV系统的Merge操作造成的写放大 levelDB等KV存储广泛采用了LSM树等结构进行存储组织，其特点就是靠上的level的数据会最终被merge sort到下层，由于多数level在磁盘文件中，这也就导致了同一KV数据的总写放大，放大的倍数就是大约是level的数目。和前边4中写放大不同的是，这种写放大并非写操作时马上就会发生写放大，而是写操作发生时会潜在的导致“未来会发生”写放大，所以这种写放大只会导致整体写代价提升，不会影响实时的延迟性能，只可能会影响磁盘带宽或者在SSD做存储设备时影响闪存耐久。FAST 16上有篇论文也专门分析了这种写放大。[8] http://blog.jcix.top/2018-06-05/write_amplification/ ...

CSS注释语法 /* 注释内容 */ 示例 /* ----------文字样式开始---------- */ /* 梦之都白色12象素文字 */ .dreamduwhite12px { color:white; font-size:12px; } /* 梦之都黑色16象素文字 */ .dreamdublack16px { color:black; font-size:16px; } /* ----------文字样式结束---------- */

HTML template, 模板 <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <!--css--> <style> body { background-color: powderblue; } </style> <!--javascript--> <script src="path/to/foo.js"></script> <script type="text/javascript"> var myVar = "hello"; function showAlert() { alert('You triggered an alert!'); } function func0() { console.log('func0') var outerDiv = document.getElementById('div_0'); // 获取最外层 div 元素的内容 var outerDivContent = outerDiv.childNodes; // 过滤出文本节点 var textContent = ''; outerDivContent.forEach(function (node) { if (node.nodeType === Node.TEXT_NODE) { textContent += node.textContent.trim() + '\n'; } }); // 输出结果 console.log(textContent.trim()); } window.onload = function () { console.log('window.onload') } </script> <!--css--> <link rel="stylesheet" type="text/css" href="foo.css"> </head> <body> body0 <button type="button" onclick="func0()">button0</button> <div id="div_0" style="background: red"> text_0 <div id="div_1" style="background: green; width: 100px;"> text_1 </div> text_2 </div> </body> </html> # 在浏览器里直接访问这个文件 file:///home/wiloon/tmp/foo.htm HTML (Document Structures) ...

Monospace fonts http://www.lowing.org/fonts/ Monospace fonts (Such as Courier or LetterGothic), or “fixed pitch” fonts, contain characters that all have the same character width, producing text that can be used to create forms, tabular material or documents that require exact text line lengths. An example of a fixed pitch font is Courier 12 pitch, which is a 10 point font that will print at exactly 12 characters per inch. <th colspan="2" align="left" bgcolor="silver"> Good Programming Font Criteria </th> Crisp clear characters. Extended characterset. Good use of whitespace. 'l', '1' and 'i' are easily distinguished '0', 'o' and 'O' are easily distinguished forward quotes from back quotes are easily distinguished -prefer mirrored appearance Clear punctuation characters, especially braces, parenthesis and brackets

emacs org mode Emacs 22 以后的版本已经集成了 org-mode，打开 .org 扩展的文件会自动进入 org 模式。 增减一个TODO项目的优先级 S-Up/Down move subtree/list item up/down M-S-UP/DOWN promote/demote heading M-LEFT/RIGHT insert new TODO entry/checkbox item M-S-RET insert TODO entry/ckbx after subtree C-S-RET C-RET加入新的同级标识 M-left将当前项提升一级 M-right将当前项降低一级 M-S-left将当前分支提升一级 M-S-right将当前分支降低一级 M-S-up将当前分支向上移动 M-S-down将当前分支向下移动 C-c C-x C-k删除当前分支 C-c C-x M-w复制当前分支 C-c C-x C-y粘贴分支 C-c C-w移动当前分支 C-c *为当前分支加入内容 3.1 关于TODO ITEM的基本知识和操作 设置TODO项目所有标题只要以TODO开头，就会变成TODO 项目。例如: *** TODO 付手机费 *** TODO 开会 更改TODO项目的状态 C-c C-t Rotate the TODO state of the current item among ...