May 2012
M T W T F S S
« Apr    
 123456
78910111213
14151617181920
21222324252627
28293031  

Open Source and Oracle — OCFS2

Back to introduce the open source projects maintained by Oracle. OCFS2 is the next generation of the Oracle Cluster File System for Linux. It is an extent based, POSIX compliant file system. Unlike the previous release (OCFS), OCFS2 is a general-purpose file system that can be used for shared Oracle home installations making management of [...]

Linux kernel timer and VMware

There are a few timer in Linux Kernel: PIT:programming interval timer,oldest PC timer device, contains three identical timers, Timer 0 can generate an interrupt and is suitable for system timekeeping. Timer 1 was historically used for RAM refresh. Timer 2 is wired to The PC speaker. Linux and most uniprocessor versions of Windows use PIT 0 [...]

Open Source and Oracle

Oracle Open Source is a web site initiated by Oracle. Its focus is to enhance and improve Linux in the interest of making Oracle products perform better, faster, and more reliably. Anyway, Open source about Oracle is a big field, many open source projects related to Oracle exists. They can be cataloged as below roughly: security [...]

liferay – a open source portal

It’s a great work! mainly using Hibernate, Struts and Spring technology. It seems that Open source changes our life, and liferay change my life these days. It‘s a good start point to learn the technology about web development, to learn the Oracle-related technology. Problem oriented, so after I finish the work, I think I must spend [...]

闲话Linux内核——学习,揣摩与玩味

最早接触Linux内核是在大三的时候,那时《操作系统》的课程设计就是进行Linux内核源代码的分析与进程调度的改进。题目是大的有点吓人,特别是在那时一个涉足未深的年轻人看来。其实那时做的事情很简单,认真认真的看了《Linux内核源代码情景分析》的前言部分(主要讲的AT&T汇编语言,内核中一些特殊的编程规则),与进程调度相关的部分,包括进程的管理,进程的切换,进程与中断,软中断,系统调用,进程互斥与同步机制。并画了几张图阐述了进程调度的路线,对spinlock机制进行了深入的剖析。明白了2.4的内核为何是非抢占式内核,进程调度器其实也不是什么神奇的东 东—— 一个函数罢了,啥叫process context。同时,为了完成“进程调度机制的改进”,看了实现可抢占的两个补丁,哦,现在已经整合进2.6了,也怪不得昨天看2.6进程调度的介绍有种似曾相识的感觉。 可以说,那时的分析完全是理论学习。对于内核编程的实践几乎没有。带来的好处最主要的在于提高了对操作系统运行的认识与提高了代码的阅读能力。   回头去看这段往事,总觉得存在着有所改进的地方。   现在看来,内核是啥呢?只是一个比较大的软件项目,可以拿它与Eclipse相比,或者mplayer相比,或者就是与任何一个开源软件处于同层次的东西,只是它更具复杂性,涉及到的软件与硬件的东西更全面罢了。   或者说,经过这几年对开源项目的接触,对软件项目的参与,Linux内核在我心目中的神秘感已然消失,Eclipse在软件架框方面应该可以算出类拔萃,EFI在BIOS这一层上也实现了新的可扩展的和良好的设备管理模型,而Linux在操作系统的层次上也应该是一个典范,值得去学习,去揣摩,去玩味。   2.6内核之于2.4内核,无疑是前进了一大步,进程调度,设备管理等等方面都形成了更良好的framework。同时也涌现出了好多优秀的传道士及其杰作,如《Linux Kernel Development Second Edition》《Linux Device Driver Third Edition》。我更想把这些带有浓厚实践性质的书籍当做进入Linux 内核世界的一个极佳的“切入点”。想起Eclipse世界一本与此类似的书《contributing to eclipse》,一个提倡的规则就是“MONKEY SEE/MONKEY DO RULE Always start by copying the structure of a similar plug-in.”。从内核中学习内核,增强内核,应该是内核编程的一个原则。   不可否认地,“情景分析”是《Linux内核源代码情景分析》的一个亮点,为过去乏味的Linux内核源代码阅读注入了一丝亮色。可是,不管怎样,这还是一个静态的过程,我更期望能从一个动态的系统中获取关于她的内幕与运作规律。   所以,如果能够设想出一些观测内核运行的切入点,并藉此实现对内核机制的动态掌握,真真切切感知内核的运行,有时更能得出一些独具特色的结论进而做出更进一步的改进。   例如对内核调度机制的分析,有以下几个简单的问题:一秒钟内内核大概会做多少次进程切换。系统一般会存在着哪些进程,哪些系统因素会显著地加剧进程切换的次数。这些进程的运行与时间存在着怎样的分布关系(即进程与时间的函数关系)。通过在内核代码中加入相应的进行统计的代码,就可以画出这种函数图出来。再通过对它的分析,就更能从中发现出一些共性东西,数学性的东西,改进的空间。   内核中的调试机制,是与内核打交道首当其冲的问题,也是进行窥探内核的途径。做为一个工具,是实现此种学习的一个必经之路。如printk,如proc文件系统等。   而实践的过程,就是一个发现问题的过程,bottom halves有几种机制,softirq, workqueue, tasklet,他们之间有哪些区别,timer的实现有哪些,在进行实践的过程中,必定会碰到这些问题,并会主动地去寻找这类问题的答案,最后的结果就是自己编写的代码能够良好的运行于内核之中。   这里有另一问题,在内核中是否可以调用一般的系统调用?如open,close,read等等。会存在什么问题?又当如何解决?呵呵,当一个一个的问题被你解决之后,与Linux内核之间的接触又亲密了一层。   从实践中来,到实践中去吧。   [...]

Debugging by Printing

采用printk进行内核的调试是一种最本的方法,为了更好地使用printk,必须对klogd, syslogd这些机制有进一步的理解。以下内容主要来自Linux Device Drivers,这里有另一本书(Linux Kernel Development)的下载。 printk的主要流程如下: ____________________________________ printk ————> |/proc/kmsg | |[FIFO queue, length __LOG_BUF_LEN] | |____________________________________| | | ——————> klogd (read file) | | /etc/syslog.conf ————-> syslogd ———–> /var/log/messages 根据日志级别,内核可能会把消息打印到当前控制台上,这个控制台可以是一个字符模式的终端、一个串口打印机或是一个并口打印机。如果优先级小于 console_loglevel 这个整数值的话,消息才能显示出来。 可以通过文本文件 /proc/sys/kernel/printk 来读取和修改控制台的日志级别。这个文件容纳了 4 个整数值。读者可能会对前面两个感兴趣:控制台的当前日志级别和默认日志级别。例如,在最近的这些内核版本中,可以通过简单地输入下面的命令使所有的内核消息得到显示: # echo 8 > /proc/sys/kernel/printk printk 函数将消息写到一个长度为 LOG_BUF_LEN(定义在 kernel/printk.c 中)字节的循环缓冲区中,然后唤醒任何正在等待消息的进程,即那些睡眠在 syslog 系统调用上的进程,或者读取 /proc/kmesg 的进程。这两个访问日志引擎的接口几乎是等价的,不过请注意,对 /proc/kmesg 进行读操作时,日志缓冲区中被读取的数据就不再保留,而 [...]