2008年05月20日
我们是5月10号坐国航9点半的航班出发的,国际航班要求提前两个多小时到机场,因此5点多就起床了,随便吃了口东西就匆匆出门了,打了辆车直奔机场。周六的早晨路上很好走,半个小时就到了,新落成的3号航站楼果然气势恢宏,大厅里很敞亮,红色的屋顶也很漂亮。顺利的办完了手续,还有两个小时才起飞,看来是来早了。闲着没事到处逛逛吧,走之前老婆交待了任务,让我在东京机场免税店给她买点化妆品,咱北京机场也有免税店,去看看价钱如何吧,店员小姐跟我介绍说她们这里的东西比香港、欧洲很多免税店都便宜。于是给老婆打电话,问价钱是否合适,答曰挺便宜的,于是在北京就完成了采购任务。
 
买完了东西也到了登机的时候了,北京离东京很近,两个半小时就到了,当地时间是中午1点过。出关的过程比较长,用了将近一个小时,其间一个同事还被接受脱鞋检查。出了机场,早有事先联系好的旅行社车在等我们,感觉日本人还是挺热情的,接待的人逐个跟我们问好,帮我们把行礼搬到了车上,然后按行程直奔箱根。
 
我们的计划是第一天傍晚前到达景点住下来,晚上洗温泉,第二天去参观三个景点,然后傍晚前到达合作方日本公司,进行几天的技术交流和学习后返回东京,在东京逛一天,然后回国。
 
东京成田机场其实是在千叶县,从机场到箱根要经过东京,第一次到日本,心里还是挺激动的,一路上眼睛不停的往外看着,日本的车是靠左侧行驶,道路修的都很好,在东京市内走的都是封闭式的高架或隧道,一路上几乎没有遇到红绿灯,我们经过了著名的东京塔,东京湾大桥,繁华的六本木,沿途也看到了迪斯尼乐园,可惜没机会去玩啊。注意看了一下路上的车,大部分都是日本产的,其中丰田的车最多,本田和尼桑也比较多,然后还有马自达、铃木等公司的车。外国的车很少,看到最多的是奔驰、宝马,象国内很常见的大众车,在日本几天就见到一辆POLO,还见过一辆标致307,其他车好像就没有见过了。相比之下,国内的小汽车简直就是八国联军了,希望以后国产车不断进步,能够占领更多的市场。
 
傍晚前终于到达下榻的旅店了,本来5点多应该天挺亮的,因为一直在下小雨,天很阴,所以提前进入了晚上,入住的旅店不大,但是很精致。旅店房间是典型的日式风格,门和窗都是木制推拉式的,地上铺的是草席,进门要脱鞋,睡觉直接在地上睡,感觉象打地铺。
 
旅店正门
晚饭是在旅店的餐厅里吃的,他们叫食堂,吃的日餐,跟在国内日料店吃感觉差不多,但是日本人的服务很到位,很多事情做的很细致,就比如果盘里的橙子,他们用刀把肉和皮分开,然后连着一点,你只需轻轻咬一口,橙子肉和皮很容易就分离了。一块吃饭的还有两拨中国人,如果不是服务员跟你说日语,甚至会想,这是在日本吗?
 
晚饭后去洗温泉,日本叫泡汤,日本泡温泉跟国内不一样,进入温泉池之前一定要先洗干净身体,然后什么都不能带进池子,包括毛巾、泳裤,不过各位不要想歪了,男女是分开的。日本的温泉池非常干净,清可见底,旅店里有三个池子,室内一个,室外两个,因为下着雨外面很冷,可能只有10度左右,所以开始一直在室内泡,后来服务员推荐我们去室外,来到外面才发现一点都不冷,大概身体被泡热了就不觉得了,室外的池子有点象江南的园林,一个不大的院子里有两个池子,有树有草,形态各异的石头,亭子在每个池子的上方,泡在热乎乎的水里,看着美丽的园林风光,听着旁边雨水的沙沙声,感觉真的很不错,真的有种回归自然的感觉。大家开始还只是泡泡,后来情绪高涨,有同事拿了相机来大家照了一些很“艺术”的照片,出于隐私这些照片就不贴了。
 
头天的行程就是这样了,由于这一天也比较累,电视也看不懂,不到11点就睡了,再睁眼醒来已是第二天早上7点了,睡得真香啊。
这是从旅店的窗口拍的,湖的名字叫河口湖,富士五湖之一,另外几个湖的名字没记住,总之都离富士山不远,天气好的时候可以看到富士山,可惜天公实在不作美,在箱根的时间一直在下雨。
 
雨后的街道
上午首先去了当地的一个和平公园,不知是否下雨的缘故,里面的人很少,到日本后有个感受,就是他们的植被保持的非常的好,所有的山上都是郁郁葱葱的,到处可见参天的大树,记得以前有报导说日本使用的木材都是从中国进口的,自己的树木是禁止砍伐的,我想从长远考虑,中国也应该对这方面有所思考。
 
公园本身并没什么特色,不过自然环境确实很好,来到这里让人感觉很舒服,心旷神怡。
 
 
照片里的几个人都是我们一行的同事,可见人之稀少。
 
这次比较有特色的景点是大涌谷,这是一个休眠的火山,山并不高,从半山腰开始就见到有白色的水往下流,空气中弥漫着难闻的气味。上到山顶,到处是烟雾弥漫,都是火山气体,味道也更浓了,是一种硫磺的味道。
 
 
 
山顶上有好几个这样的坑,有的里面还咕咕的冒着泡,温度也比较高。这里还卖一种黑鸡蛋,就是把鸡蛋放到火山水里煮,出来就变成黑色的了,据说可以延年益寿,吃一个可以多活7年,因此我们都买来吃了。
 
大涌谷的下一站是芦之湖,这也是一个温泉的胜地,天气好的时候一边泡着温泉一边看着富士山,据说是日本人心目中很惬意的事情。除此之外,此湖也没什么特别之处。
 
坐照片中的游船在湖上转了一圈之后,我们此行短暂的游览就算结束了,接下来是三天的工作时间,由于所住的地方比较偏僻,所以也没什么可游玩的。
 
工作期间住的地方叫水户,小城市不大,但也很精致,街道很干净,基础设施也都很健全,发达国家和发展中国家还是不一样啊。旅馆很小,一个人住一个房间,面积估计10平米多点吧,不过设施还都不错,液晶电视,免费宽带,小冰箱,特别的是带加热的马桶,坐上去热乎乎的,还能喷热水洗PP,这种以前光是听说,第一次试感觉还真是蛮舒服的。日本人做事情还真是周到细致。
 
工作期间认识了两个日方的员工,都是在日本留学后留下来在当地工作的中国人,碰到同胞心里很亲切,他们对我们也都很热情,很多时候还能帮我们说话,虽然他们是日方的雇员,但是毕竟还是同胞。听他们讲奥运火炬在日本长野传递的时候,他们也去现场助威了,路上还跟支持藏独的人打了一仗。
 
日本人工作非常辛苦,来之前就听一个在日本工作的同学讲,他每天工作达到13个小时,感觉难以置信。来到这边之后,听他们讲加班确实也是家常便饭。后来住东京的时候,都夜里12点多了,街道上人还是很多。
 
另外感觉日本人非常的有计划,什么都要事先预约,按照日程表办事。日本的企业也比较注重管理和保密,在我们与之交流的日本公司里,他们规定电脑一律不准带出公司,不能用U盘,等等,而且一律不准拍照。感觉对知识产权的保护非常重视,不象国内,拿个U盘随便拷,很容易泄密。
 
日本上班族男人的装束几乎一摸一样,都是一身深色西服,衬衫领带,一个黑色的公文包,很职业。女人的变化稍微多一些,但也比较职业,似乎没有穿着牛仔裤、吊带、凉拖去上班的。而且日本人好像很经冻,一年四季都有人穿裙子,不过在东京,冬天最冷的时候也不会到零度以下。
在东京街头遇到的一群日本中学生。
 
有些人比较关心日本的美眉漂不漂亮,以我短暂的观察,其实跟国内也差不多,但是可能是因为饮食的关系,日本的美眉普遍比较苗条。另外一点,在北京流行什么都是一股风,比如今年好像比较流行黑色丝袜,大街上的女士就全是一色的黑丝袜,相反日本的美眉就没有一窝蜂一种装束的现象。各位爱美的美眉,个性才是美,这是我的看法。
 
日本的AV女优比较有名,在日本住的几个旅馆里都有成人频道可以收看,但都是要付费的,需要买1000日元的预付费卡,插在电视下方的一个盒子里才可以收看。
 
回来前在东京停留了多半天的时间,去看了一个海滨公园,还去上野、皇宫和靖国神社看了一眼,不多介绍了,看图吧。
皇宫外苑
臭名昭著的靖国神社
葛西邻海公园
据说比较有名的上野不忍池
在回国的飞机上看到了富士山,各位如果坐东京到北京的航班,起飞大约20多分钟后在左侧窗口能看到富士山,前提是没有云层遮挡的话,也算弥补了一个遗憾。
短暂的日本之行结束了,这次去日本让我的许多想法发生了变化。以前在国内的时候,从各种途径的信息告诉我,日本不是一个友好的国家,买汽车一定不买日货,等等,去之前我特意把电脑的桌面换成了长城,以表明我的爱国心。来到日本后,从机场一落地,到与日方公司的工作交流,以及与日本各服务业人员的接触,日本人对待中国人还是很友好的,右翼势力在日本也是少数。我想无论中国、日本,人民都是善良的,我们需要对日本的右翼势力和军国主义提高警惕,但是也不能认定日本民族就是一个敌对的民族,我想作为一个理性、大度的中国人,应该有这样的认识,我希望北京奥运期间,各国的运动员在中国都能体会到中国人的热情和好客。
 
这次在日本出差期间,刚好国内发生了大地震,回国之后每天都接受大量的有关地震的报导,心情非常的沉痛,但也非常的骄傲,因为我们中国人在这次灾难面前表现的非常的团结,政府处理的也很及时到位,中国是很有希望的。日本有很多对中国友好的公司也提供了很多的援助,包括与我们有合作的日本公司就捐助了800万元,日本政府也派出了救援队,所以在我心中日本的印象好了不少。
 
日本人的环保意识,日本人的敬业和认真细致的性格,政府对下一代的关心和爱护,都是值得我们学习的,中国发生地震后,日本决定对国内的所有校舍进行防震评估和改造,因为他们认为学生是国家的未来,因此学校的建筑应该是最结实的,我想中国政府也应该采取相应的措施,看着那么多的学生在地震中丧生,真的让人心痛啊。中国人民在这次灾难之后,我们最应该做的就是团结一心,努力把自己的工作做好,每个人都认真工作,国家才会更美好,更富强,真心希望祖国越来越好。
2008年04月15日

随 着Linux2.6的发布,由于2.6内核做了教的改动,各个设备的驱动程序在不同程度上要进行改写。为了方便各位Linux爱好者我把自己整理的这分文 档share出来。该文当列举了2.6内核同以前版本的绝大多数变化,可惜的是由于时间和精力有限没有详细列出各个函数的用法。

特别声明:该文档中的内容来自http://lwn.net,该网也上也有各个函数的较为详细的说明可供各位参考。

1、 使用新的入口

必须包含 <linux/init.h>

module_init(your_init_func);

module_exit(your_exit_func);

老版本:int init_module(void);

void cleanup_module(voi);

2.4中两种都可以用,对如后面的入口函数不必要显示包含任何头文件。

2、 GPL

MODULE_LICENSE("Dual BSD/GPL");

老版本:MODULE_LICENSE("GPL");

3、 模块参数

必须显式包含<linux/moduleparam.h>

module_param(name, type, perm);

module_param_named(name, value, type, perm);

参数定义

module_param_string(name, string, len, perm);

module_param_array(name, type, num, perm);

老版本:MODULE_PARM(variable,type);

MODULE_PARM_DESC(variable,type);

4、 模块别名

MODULE_ALIAS("alias-name");

这是新增的,在老版本中需在/etc/modules.conf配置,现在在代码中就可以实现。

5、 模块计数

int try_module_get(&module);

module_put();

老版本:MOD_INC_USE_COUNT 和 MOD_DEC_USE_COUNT

6、 符号导出

只有显示的导出符号才能被其他模块使用,默认不导出所有的符号,不必使用EXPORT_NO_SYMBOLS

老板本:默认导出所有的符号,除非使用EXPORT_NO_SYMBOLS

7、 内核版本检查

需要在多个文件中包含<linux/module.h>时,不必定义__NO_VERSION__

老版本:在多个文件中包含<linux/module.h>时,除在主文件外的其他文件中必须定义__NO_VERSION__,防止版本重复定义。

8、 设备号

kdev_t被废除不可用,新的dev_t拓展到了32位,12位主设备号,20位次设备号。

unsigned int iminor(struct inode *inode);

unsigned int imajor(struct inode *inode);

老版本:8位主设备号,8位次设备号

int MAJOR(kdev_t dev);

int MINOR(kdev_t dev);

9、 内存分配头文件变更

所有的内存分配函数包含在头文件<linux/slab.h>,而原来的<linux/malloc.h>不存在

老版本:内存分配函数包含在头文件<linux/malloc.h>

10、 结构体的初试化

gcc开始采用ANSI C的struct结构体的初始化形式:

static struct some_structure = {

.field1 = value,

.field2 = value,

..

};

老版本:非标准的初试化形式

static struct some_structure = {

field1: value,

field2: value,

..

};

11、 用户模式帮助器

int call_usermodehelper(char *path, char **argv, char **envp,int wait);

新增wait参数

12、 request_module()

request_module("foo-device-%d", number);

老版本:

char module_name[32];

printf(module_name, "foo-device-%d", number);

request_module(module_name);

13、 dev_t引发的字符设备的变化

1、取主次设备号为

unsigned iminor(struct inode *inode);

unsigned imajor(struct inode *inode);

2、老的register_chrdev()用法没变,保持向后兼容,但不能访问设备号大于256的设备。

3、新的接口为

a)注册字符设备范围

int register_chrdev_region(dev_t from, unsigned count, char *name);

b)动态申请主设备号

int alloc_chrdev_region(dev_t *dev, unsigned baseminor, unsigned count, char

*name);

看了这两个函数郁闷吧^_^!怎么和file_operations结构联系起来啊?别急!

c)包含 <linux/cdev.h>,利用struct cdev和file_operations连接

struct cdev *cdev_alloc(void);

void cdev_init(struct cdev *cdev, struct file_operations *fops);

int cdev_add(struct cdev *cdev, dev_t dev, unsigned count);

(分别为,申请cdev结构,和fops连接,将设备加入到系统中!好复杂啊!)

d)void cdev_del(struct cdev *cdev);

只有在cdev_add执行成功才可运行。

e)辅助函数

kobject_put(&cdev->kobj);

struct kobject *cdev_get(struct cdev *cdev);

void cdev_put(struct cdev *cdev);

这一部分变化和新增的/sys/dev有一定的关联。

14、 新增对/proc的访问操作

<linux/seq_file.h>

以前的/proc中只能得到string, seq_file操作能得到如long等多种数据。

相关函数:

static struct seq_operations 必须实现这个类似file_operations得数据中得各个成

员函数。

seq_printf();

int seq_putc(struct seq_file *m, char c);

int seq_puts(struct seq_file *m, const char *s);

int seq_escape(struct seq_file *m, const char *s, const char *esc);

int seq_path(struct seq_file *m, struct vfsmount *mnt,

struct dentry *dentry, char *esc);

seq_open(file, &ct_seq_ops);

等等

15、 底层内存分配

1、<linux/malloc.h>头文件改为<linux/slab.h>

2、分配标志GFP_BUFFER被取消,取而代之的是GFP_NOIO 和 GFP_NOFS

3、新增__GFP_REPEAT,__GFP_NOFAIL,__GFP_NORETRY分配标志

4、页面分配函数alloc_pages(),get_free_page()被包含在<linux/gfp.h>中

5、对NUMA系统新增了几个函数:

a) struct page *alloc_pages_node(int node_id,

unsigned int gfp_mask,

unsigned int order);

b) void free_hot_page(struct page *page);

c) void free_cold_page(struct page *page);

6、 新增Memory pools

<linux/mempool.h>

mempool_t *mempool_create(int min_nr,

mempool_alloc_t *alloc_fn,

mempool_free_t *free_fn,

void *pool_data);

void *mempool_alloc(mempool_t *pool, int gfp_mask);

void mempool_free(void *element, mempool_t *pool);

int mempool_resize(mempool_t *pool, int new_min_nr, int gfp_mask);

16、 per-CPU变量

get_cpu_var();

put_cpu_var();

void *alloc_percpu(type);

void free_percpu(const void *);

per_cpu_ptr(void *ptr, int cpu)

get_cpu_ptr(ptr)

put_cpu_ptr(ptr)

老版本使用

DEFINE_PER_CPU(type, name);

EXPORT_PER_CPU_SYMBOL(name);

EXPORT_PER_CPU_SYMBOL_GPL(name);

DECLARE_PER_CPU(type, name);

DEFINE_PER_CPU(int, mypcint);

2.6内核采用了可剥夺得调度方式这些宏都不安全。

17、 内核时间变化

1、现在的各个平台的HZ为

Alpha: 1024/1200; ARM: 100/128/200/1000; CRIS: 100; i386: 1000; IA-64:

1024; M68K: 100; M68K-nommu: 50-1000; MIPS: 100/128/1000; MIPS64: 100;

PA-RISC: 100/1000; PowerPC32: 100; PowerPC64: 1000; S/390: 100; SPARC32:

100; SPARC64: 100; SuperH: 100/1000; UML: 100; v850: 24-100; x86-64: 1000.

2、由于HZ的变化,原来的jiffies计数器很快就溢出了,引入了新的计数器jiffies_64

3、#include <linux/jiffies.h>

u64 my_time = get_jiffies_64();

4、新的时间结构增加了纳秒成员变量

struct timespec current_kernel_time(void);

5、他的timer函数没变,新增

void add_timer_on(struct timer_list *timer, int cpu);

6、新增纳秒级延时函数

ndelay();

7、POSIX clocks 参考kernel/posix-timers.c

18、 工作队列(workqueue)

1、任务队列(task queue )接口函数都被取消,新增了workqueue接口函数

struct workqueue_struct *create_workqueue(const char *name);

DECLARE_WORK(name, void (*function)(void *), void *data);

INIT_WORK(struct work_struct *work,

void (*function)(void *), void *data);

PREPARE_WORK(struct work_struct *work,

void (*function)(void *), void *data);

2、申明struct work_struct结构

int queue_work(struct workqueue_struct *queue,

struct work_struct *work);

int queue_delayed_work(struct workqueue_struct *queue,

struct work_struct *work,

unsigned long delay);

int cancel_delayed_work(struct work_struct *work);

void flush_workqueue(struct workqueue_struct *queue);

void destroy_workqueue(struct workqueue_struct *queue);

int schedule_work(struct work_struct *work);

int schedule_delayed_work(struct work_struct *work, unsigned long

delay);

19、 新增创建VFS的"libfs"

libfs给创建一个新的文件系统提供了大量的API.

主要是对struct file_system_type的实现。

参考源代码:

drivers/hotplug/pci_hotplug_core.c

drivers/usb/core/inode.c

drivers/oprofile/oprofilefs.c

fs/ramfs/inode.c

fs/nfsd/nfsctl.c (simple_fill_super() example)

20、 DMA的变化

未变化的有:

void *pci_alloc_consistent(struct pci_dev *dev, size_t size,

dma_addr_t *dma_handle);

void pci_free_consistent(struct pci_dev *dev, size_t size,

void *cpu_addr, dma_addr_t dma_handle);

变化的有:

1、 void *dma_alloc_coherent(struct device *dev, size_t size,

dma_addr_t *dma_handle, int flag);

void dma_free_coherent(struct device *dev, size_t size,

void *cpu_addr, dma_addr_t dma_handle);

2、列举了映射方向:

enum dma_data_direction {

DMA_BIDIRECTIONAL = 0,

DMA_TO_DEVICE = 1,

DMA_FROM_DEVICE = 2,

DMA_NONE = 3,

};

3、单映射

dma_addr_t dma_map_single(struct device *dev, void *addr,

size_t size,

enum dma_data_direction direction);

void dma_unmap_single(struct device *dev, dma_addr_t dma_addr,

size_t size,

enum dma_data_direction direction);

4、页面映射

dma_addr_t dma_map_page(struct device *dev, struct page *page,

unsigned long offset, size_t size,

enum dma_data_direction direction);

void dma_unmap_page(struct device *dev, dma_addr_t dma_addr,

size_t size,

enum dma_data_direction direction);

5、有关scatter/gather的函数:

int dma_map_sg(struct device *dev, struct scatterlist *sg,

int nents, enum dma_data_direction direction);

void dma_unmap_sg(struct device *dev, struct scatterlist *sg,

int nhwentries, enum dma_data_direction direction);

6、非一致性映射(Noncoherent DMA mappings)

void *dma_alloc_noncoherent(struct device *dev, size_t size,

dma_addr_t *dma_handle, int flag);

void dma_sync_single_range(struct device *dev, dma_addr_t dma_handle,

unsigned long offset, size_t size,

enum dma_data_direction direction);

void dma_free_noncoherent(struct device *dev, size_t size,

void *cpu_addr, dma_addr_t dma_handle);

7、DAC (double address cycle)

int pci_dac_set_dma_mask(struct pci_dev *dev, u64 mask);

void pci_dac_dma_sync_single(struct pci_dev *dev,

dma64_addr_t dma_addr,

size_t len, int direction);

21、 互斥

新增seqlock主要用于:

1、少量的数据保护

2、数据比较简单(没有指针),并且使用频率很高

3、对不产生任何副作用的数据的访问

4、访问时写者不被饿死

<linux/seqlock.h>

初始化

seqlock_t lock1 = SEQLOCK_UNLOCKED;

或seqlock_t lock2; seqlock_init(&lock2);

void write_seqlock(seqlock_t *sl);

void write_sequnlock(seqlock_t *sl);

int write_tryseqlock(seqlock_t *sl);

void write_seqlock_irqsave(seqlock_t *sl, long flags);

void write_sequnlock_irqrestore(seqlock_t *sl, long flags);

void write_seqlock_irq(seqlock_t *sl);

void write_sequnlock_irq(seqlock_t *sl);

void write_seqlock_bh(seqlock_t *sl);

void write_sequnlock_bh(seqlock_t *sl);

unsigned int read_seqbegin(seqlock_t *sl);

int read_seqretry(seqlock_t *sl, unsigned int iv);

unsigned int read_seqbegin_irqsave(seqlock_t *sl, long flags);

int read_seqretry_irqrestore(seqlock_t *sl, unsigned int iv, long

flags);

22、 内核可剥夺

<linux/preempt.h>

preempt_disable();

preempt_enable_no_resched();

preempt_enable_noresched();

preempt_check_resched();

23、睡眠和唤醒

1、原来的函数可用,新增下列函数:

prepare_to_wait_exclusive();

prepare_to_wait();

2、等待队列的变化

typedef int (*wait_queue_func_t)(wait_queue_t *wait,

unsigned mode, int sync);

void init_waitqueue_func_entry(wait_queue_t *queue,

wait_queue_func_t func);

24、 新增完成事件(completion events)

<linux/completion.h>

init_completion(&my_comp);

void wait_for_completion(struct completion *comp);

void complete(struct completion *comp);

void complete_all(struct completion *comp);

25、 RCU(Read-copy-update)

rcu_read_lock();

void call_rcu(struct rcu_head *head, void (*func)(void *arg),

void *arg);

26、 中断处理

1、中断处理有返回值了。

IRQ_RETVAL(handled);

2、cli(), sti(), save_flags(), 和 restore_flags()不再有效,应该使用local_save

_flags() 或local_irq_disable()。

3、synchronize_irq()函数有改动

4、新增int can_request_irq(unsigned int irq, unsigned long flags);

5、 request_irq() 和free_irq() 从 <linux/sched.h>改到了 <linux/interrupt.h>

27、 异步I/O(AIO)

<linux/aio.h>

ssize_t (*aio_read) (struct kiocb *iocb, char __user *buffer,

size_t count, loff_t pos);

ssize_t (*aio_write) (struct kiocb *iocb, const char __user *buffer,

size_t count, loff_t pos);

int (*aio_fsync) (struct kiocb *, int datasync);

新增到了file_operation结构中。

is_sync_kiocb(struct kiocb *iocb);

int aio_complete(struct kiocb *iocb, long res, long res2);

28、 网络驱动

1、struct net_device *alloc_netdev(int sizeof_priv, const char *name,

void (*setup)(struct net_device *));

struct net_device *alloc_etherdev(int sizeof_priv);

2、新增NAPI(New API)

void netif_rx_schedule(struct net_device *dev);

void netif_rx_complete(struct net_device *dev);

int netif_rx_ni(struct sk_buff *skb);

(老版本为netif_rx())

29、 USB驱动

老版本struct usb_driver取消了,新的结构体为

struct usb_class_driver {

char *name;

struct file_operations *fops;

mode_t mode;

int minor_base;

};

int usb_submit_urb(struct urb *urb, int mem_flags);

int (*probe) (struct usb_interface *intf,

const struct usb_device_id *id);

30、 block I/O 层

这一部分做的改动最大。不祥叙。

31、 mmap()

int remap_page_range(struct vm_area_struct *vma, unsigned long from,

unsigned long to, unsigned long size,

pgprot_t prot);

int io_remap_page_range(struct vm_area_struct *vma, unsigned long from,

unsigned long to, unsigned long size,

pgprot_t prot);

struct page *(*nopage)(struct vm_area_struct *area,

unsigned long address,

int *type);

int (*populate)(struct vm_area_struct *area, unsigned long address,

unsigned long len, pgprot_t prot, unsigned long pgoff,

int nonblock);

int install_page(struct mm_struct *mm, struct vm_area_struct *vma,

unsigned long addr, struct page *page,

pgprot_t prot);

struct page *vmalloc_to_page(void *address);

32、 零拷贝块I/O(Zero-copy block I/O)

struct bio *bio_map_user(struct block_device *bdev,

unsigned long uaddr,

unsigned int len,

int write_to_vm);

void bio_unmap_user(struct bio *bio, int write_to_vm);

int get_user_pages(struct task_struct *task,

struct mm_struct *mm,

unsigned long start,

int len,

int write,

int force,

struct page **pages,

struct vm_area_struct **vmas);

33、 高端内存操作kmaps

void *kmap_atomic(struct page *page, enum km_type type);

void kunmap_atomic(void *address, enum km_type type);

struct page *kmap_atomic_to_page(void *address);

老版本:kmap() 和 kunmap()。

34:驱动模型

主要用于设备管理。

1、 sysfs

2、 Kobjects()

      35. 宏mem_map_reserver和mem_map_unreservereserve a page in the device driver in 2.4. defined in <linux/wrapper.h>, 2.6的内核中由SetPageReserved和ClearPageReserved 实现,功能相同,但所需包含的头文件变为<linux/page-flags.h>.

 

 

2008年04月10日

Learning about Linux Processes

By Amit Saha

So, What Is A Process?

Quoting from Robert Love’s book Linux Kernel Development, "The Process is one of the fundamental abstractions in Unix Operating Systems, the other fundamental abstraction being files." A process is a program in execution. It consists of the executing program code, a set of resources such as open files, internal kernel data, an address space, one or more threads of execution and a data section containing global variables.

Process Descriptors

Each process has process descriptors associated with it. These hold the information used to keep track of a process in memory. Among the various pieces of information stored about a process are its PID, state, parent process, children, siblings, processor registers, list of open files and address space information.

The Linux kernel uses a circular doubly-linked list of struct task_structs to store these process descriptors. This structure is declared in linux/sched.h. Here are a few fields from kernel 2.6.15-1.2054_FC5, starting at line 701:

    701 struct task_struct {    702         volatile long state;    /* -1 unrunnable, 0 runnable, >0 stopped */    703         struct thread_info *thread_info;     .     .    767         /* PID/PID hash table linkage. */    768         struct pid pids[PIDTYPE_MAX];     .     .    798         char comm[TASK_COMM_LEN]; /* executable name excluding path

The first line of the structure defines the field state as volatile long. This variable is used to keep track of the execution state of the process, defined by the following macros:

#define TASK_RUNNING            0#define TASK_INTERRUPTIBLE      1#define TASK_UNINTERRUPTIBLE    2#define TASK_STOPPED            4#define TASK_TRACED             8/* in tsk->exit_state */#define EXIT_ZOMBIE             16#define EXIT_DEAD               32/* in tsk->state again */#define TASK_NONINTERACTIVE     64

The volatile keyword is worth noting – see http://www.kcomputing.com/volatile.html for more information.

Linked Lists

Before we look at how tasks/processes (we will use the two words as synonyms) are stored by the kernel, we need to understand how the kernel implements circular linked lists. The implementation that follows is a standard that is used across all the kernel sources. The linked list is declared in linux/list.h and the data structure is simple:

 struct list_head {         struct list_head *next, *prev; };

This file also defines several ready-made macros and functions which you can use to manipulate linked lists. This standardizes the linked list implementation to prevent people "reinventing the wheel" and introducing new bugs.

Here are some kernel linked list references:

The Kernel Task List

Let us now see how the linux kernel uses circular doubly-linked lists to store the records of processes. Searching for struct list_head inside the definition of struct task_struct gives us:

struct list_head tasks;

This line shows us that the kernel is using a circular linked list to store the tasks. Thsi means we can use the standard kernel linked list macros and functions to traverse through the complete task list.

init is the "mother of all processes" on a Linux system. Thus it is represented at the beginning of the list, although strictly speaking there is no head since this is a circular list. The init task’s process descriptor is statically allocated:

extern struct task_struct init_task;

The following shows the linked list representation of processes in memory:

Linked List Figure

Several other macros and functions are available to help us traverse this list:

for_each_process() is a macro which iterates over the entire task list. It is defined as follows in linux/sched.h:

#define for_each_process(p) \        for (p = &init_task ; (p = next_task(p)) != &init_task ; )

next_task() is a macro defined in linux/sched.h which returns the next task in the list:

#define next_task(p)    list_entry((p)->tasks.next, struct task_struct, tasks)

list_entry() is a macro defined in linux/list.h:

/* * list_entry - get the struct for this entry * @ptr:        the &struct list_head pointer. * @type:       the type of the struct this is embedded in. * @member:     the name of the list_struct within the struct. */#define list_entry(ptr, type, member) \        container_of(ptr, type, member)

The macro container_of() is defined as follows:

#define container_of(ptr, type, member) ({                      \        const typeof( ((type *)0)->member ) *__mptr = (ptr);    \        (type *)( (char *)__mptr - offsetof(type,member) );})

Thus if we can traverse through the entire task list we can have all the processes running on the system. This can be done with the macro for_each_process(task) , where task is a pointer of struct task_struct type. Here is an example kernel module, from Linux Kernel Development:

    /* ProcessList.c     Robert Love Chapter 3    */    #include < linux/kernel.h >    #include < linux/sched.h >    #include < linux/module.h >

    int init_module(void)    {    struct task_struct *task;    for_each_process(task)    {    printk("%s [%d]\n",task->comm , task->pid);    }

    return 0;    }

    void cleanup_module(void)    {    printk(KERN_INFO "Cleaning Up.\n");    }

The current macro is a link to the process descriptor (a pointer to a task_struct)of the currently executing process. How current achieves its task is architecture dependent. On an x86 this is done by the function current_thread_info() in asm/thread_info.h

   /* how to get the thread information struct from C */   static inline struct thread_info *current_thread_info(void)   {           struct thread_info *ti;           __asm__("andl %%esp,%0; ":"=r" (ti) : "0" (~(THREAD_SIZE - 1)));           return ti;   }

Finally current dereferences the task member of the thread_info structure which is reproduced below from asm/thread_info.h by current_thread_info()->task;

   struct thread_info {           struct task_struct      *task;          /* main task structure */           struct exec_domain      *exec_domain;   /* execution domain */           unsigned long           flags;          /* low level flags */           unsigned long           status;         /* thread-synchronous flags */           __u32                   cpu;            /* current CPU */           int                     preempt_count;  /* 0 => preemptable, <0 => BUG */

           mm_segment_t            addr_limit;     /* thread address space:                                                      0-0xBFFFFFFF for user-thread                                                      0-0xFFFFFFFF for kernel-thread                                                   */           void                    *sysenter_return;           struct restart_block    restart_block;

           unsigned long           previous_esp;   /* ESP of the previous stack in case                                                      of nested (IRQ) stacks                                                   */           __u8                    supervisor_stack[0];   };

Using the current macro and init_task we can write a kernel module to trace from the current process back to init.

/*Traceroute to init   traceinit.cRobert Love Chapter 3*/  #include < linux/kernel.h >  #include < linux/sched.h >  #include < linux/module.h >

  int init_module(void)  {  struct task_struct *task;

   for(task=current;task!=&init_task;task=task->parent)   //current is a macro which points to the current task / process   {   printk("%s [%d]\n",task->comm , task->pid);   }

   return 0;   }

   void cleanup_module(void)   {   printk(KERN_INFO "Cleaning up 1.\n");   }

Well, we have just started in our quest to learn about one of the fundamental abstractions of a linux system — the process. In (possible) future extensions of this, we shall take a look at several others.

‘Till then, Happy hacking!

Other Resources:

     obj-m +=ProcessList.o     obj-m +=traceinit.o     all:             make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

     clean:             make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

Linux内存管理

摘要:本章首先以应用程序开发者的角度审视Linux的进程内存管理,在此基础上逐步深入到内核中讨论系统物理内存管理和内核内存的使用方法。力求从外到内、水到渠成地引导网友分析Linux的内存管理与使用。在本章最后,我们给出一个内存映射的实例,帮助网友们理解内核内存管理与用户内存管理之间的关系,希望大家最终能驾驭Linux内存管理。

前言

内存管理一向是所有操作系统书籍不惜笔墨重点讨论的内容,无论市面上或是网上都充斥着大量涉及内存管理的教材和资料。因此,我们这里所要写的Linux内存管理采取避重就轻的策略,从理论层面就不去班门弄斧,贻笑大方了。我们最想做的和可能做到的是从开发者的角度谈谈对内存管理的理解,最终目的是把我们在内核开发中使用内存的经验和对Linux内存管理的认识与大家共享。

当然,这其中我们也会涉及到一些诸如段页等内存管理的基本理论,但我们的目的不是为了强调理论,而是为了指导理解开发中的实践,所以仅仅点到为止,不做深究。

遵循“理论来源于实践”的“教条”,我们先不必一下子就钻入内核里去看系统内 存到底是如何管理,那样往往会让你陷入似懂非懂的窘境(我当年就犯了这个错误!)。所以最好的方式是先从外部(用户编程范畴)来观察进程如何使用内存,等 到大家对内存的使用有了较直观的认识后,再深入到内核中去学习内存如何被管理等理论知识。最后再通过一个实例编程将所讲内容融会贯通。

进程与内存

进程如何使用内存?

毫无疑问,所有进程(执行的程序)都必须占用一定数量的内存,它或是用来存放从磁盘载入的程序代码,或是存放取自用户输入的数据等等。不过进程对这些内存的管理方式因内存用途不一而不尽相同,有些内存是事先静态分配和统一回收的,而有些却是按需要动态分配和回收的。

对任何一个普通进程来讲,它都会涉及到5种不同的数据段。稍有编程知识的朋友都能想到这几个数据段中包含有“程序代码段”、“程序数据段”、“程序堆栈段”等。不错,这几种数据段都在其中,但除了以上几种数据段之外,进程还另外包含两种数据段。下面我们来简单归纳一下进程对应的内存空间中所包含的5种不同的数据区。

代码段:代码段是用来存放可执行文件的操作指令,也就是说是它是可执行程序在内存中的镜像。代码段需要防止在运行时被非法修改,所以只准许读取操作,而不允许写入(修改)操作——它是不可写的。

数据段:数据段用来存放可执行文件中已初始化全局变量,换句话说就是存放程序静态分配[1]的变量和全局变量。

BSS[2]BSS段包含了程序中未初始化的全局变量,在内存中 bss段全部置零。

堆(heap:堆是用于存放进程运行中被动态分配的内存段,它的大小并不固定,可动态扩张或缩减。当进程调用malloc等函数分配内存时,新分配的内存就被动态添加到堆上(堆被扩张);当利用free等函数释放内存时,被释放的内存从堆中被剔除(堆被缩减)

是用户存放程序临时创建的局部变量,也就是说我们函数括弧“{}”中定义的变量(但不包括static声明的变量,static意味着在数据段中存放变量)。除此以外,在函数被调用时,其参数也会被压入发起调用的进程中,并且待到调用结束后,函数的返回值也会被存放回中。由于的先进先出特点,所以特别方便用来保存/恢复调用现场。从这个意义上讲,我们可以把堆栈看成一个寄存、交换临时数据的内存区。

进程如何组织这些区域?

上述几种内存区域中数据段、BSS和堆通常是被连续存储的——内存位置上是连续的,而代码段和往往会被独立存放。有趣的是,堆和两个区域关系很“暧昧”,他们一个向下“长”(i386体系结构中向下、堆向上),一个向上“长”,相对而生。但你不必担心他们会碰头,因为他们之间间隔很大(到底大到多少,你可以从下面的例子程序计算一下),绝少有机会能碰到一起。

下图简要描述了进程内存区域的分布:

“事实胜于雄辩”,我们用一个小例子(原形取自《User-Level Memory Management)来展示上面所讲的各种内存区的差别与位置。

#include<stdio.h>

#include<malloc.h>

#include<unistd.h>

int bss_var;

int data_var0=1;

int main(int argc,char **argv)

{

  printf("below are addresses of types of process’s mem\n");

  printf("Text location:\n");

  printf("\tAddress of main(Code Segment):%p\n",main);

  printf("____________________________\n");

  int stack_var0=2;

  printf("Stack Location:\n");

  printf("\tInitial end of stack:%p\n",&stack_var0);

  int stack_var1=3;

  printf("\tnew end of stack:%p\n",&stack_var1);

  printf("____________________________\n");

  printf("Data Location:\n");

  printf("\tAddress of data_var(Data Segment):%p\n",&data_var0);

  static int data_var1=4;

  printf("\tNew end of data_var(Data Segment):%p\n",&data_var1);

  printf("____________________________\n");

  printf("BSS Location:\n");

  printf("\tAddress of bss_var:%p\n",&bss_var);

  printf("____________________________\n");

  char *b = sbrk((ptrdiff_t)0);

  printf("Heap Location:\n");

  printf("\tInitial end of heap:%p\n",b);

  brk(b+4);

  b=sbrk((ptrdiff_t)0);

  printf("\tNew end of heap:%p\n",b);

return 0;

 }

它的结果如下

below are addresses of types of process’s mem

Text location:

   Address of main(Code Segment):0×8048388

____________________________

Stack Location:

   Initial end of stack:0xbffffab4

   new end of stack:0xbffffab0

____________________________

Data Location:

   Address of data_var(Data Segment):0×8049758

   New end of data_var(Data Segment):0×804975c

____________________________

BSS Location:

   Address of bss_var:0×8049864

____________________________

Heap Location:

   Initial end of heap:0×8049868

   New end of heap:0×804986c

利用size命令也可以看到程序的各段大小,比如执行size example会得到

text data bss dec hex filename

1654 280   8 1942 796 example

但这些数据是程序编译的静态统计,而上面显示的是进程运行时的动态值,但两者是对应的。

通过前面的例子,我们对进程使用的逻辑内存分布已先睹为快。这部分我们就继续进入操作系统内核看看,进程对内存具体是如何进行分配和管理的。

从用户向内核看,所使用的内存表象形式会依次经历“逻辑地址”——“线性地址”——“物理地址”几种形式(关于几种地址的解释在前面已经讲述了)。逻辑地址经段机制转化成线性地址;线性地址又经过页机制转化为物理地址。(但是我们要知道Linux系统虽然保留了段机制,但是将所有程序的段地址都定死为0-4G,所以虽然逻辑地址和线性地址是两种不同的地址空间,但在Linux中逻辑地址就等于线性地址,它们的值是一样的)。沿着这条线索,我们所研究的主要问题也就集中在下面几个问题。

1.     进程空间地址如何管理?

2.     进程地址如何映射到物理内存?

3.     物理内存如何被管理?

以及由上述问题引发的一些子问题。如系统虚拟地址分布内存分配接口;连续内存分配与非连续内存分配等。

 

进程内存空间

Linux操作系统采用虚拟内存管理技术,使得每个进程都有各自互不干涉的进程地址空间。该空间是块大小为4G的线性虚拟空间,用户所看到和接触到的都是该虚拟地址,无法看到实际的物理内存地址。利用这种虚拟地址不但能起到保护操作系统的效果(用户不能直接访问物理内存),而且更重要的是,用户程序可使用比实际物理内存更大的地址空间(具体的原因请看硬件基础部分)。

在讨论进程空间细节前,这里先要澄清下面几个问题:

l         第一、4G的进程地址空间被人为的分为两个部分——用户空间与内核空间。用户空间从03G0xC0000000),内核空间占据3G4G。用户进程通常情况下只能访问用户空间的虚拟地址,不能访问内核空间虚拟地址。只有用户进程进行系统调用(代表用户进程在内核态执行)等时刻可以访问到内核空间。

l         第二、用户空间对应进程,所以每当进程切换,用户空间就会跟着变化;而内核空间是由内核负责映射,它并不会跟着进程改变,是固定的。内核空间地址有自己对应的页表init_mm.pgd,用户进程各自有不同的页表。

l         第三、每个进程的用户空间都是完全独立、互不相干的。不信的话,你可以把上面的程序同时运行10次(当然为了同时运行,让它们在返回前一同睡眠100秒吧),你会看到10个进程占用的线性地址一模一样。

 

进程内存管理

进程内存管理的对象是进程线性地址空间上的内存镜像这些内存镜像其实就是进程使用的虚拟内存区域(memory region)。进程虚拟空间是个3264位的“平坦”(独立的连续区间)地址空间(空间的具体大小取决于体系结构)。要统一管理这么大的平坦空间可绝非易事,为了方便管理,虚拟空间被划分为许多大小可变的(但必须是4096的倍数)内存区域,这些区域在进程线性地址中像停车位一样有序排列。这些区域的划分原则是“将访问属性一致的地址空间存放在一起”,所谓访问属性在这里无非指的是“可读、可写、可执行等”。

如果你要查看某个进程占用的内存区域,可以使用命令cat /proc/<pid>/maps获得(pid是进程号,你可以运行上面我们给出的例子——./example &;pid便会打印到屏幕),你可以发现很多类似于下面的数字信息。

由于程序example使用了动态库,所以除了example本身使用的内存区域外,还会包含那些动态库使用的内存区域(区域顺序是:代码段、数据段、bss段)。

我们下面只抽出和example有关的信息,除了前两行代表的代码段和数据段外,最后一行是进程使用的空间。

——————————————————————————-

08048000 – 08049000 r-xp 00000000 03:03 439029                               /home/mm/src/example

08049000 – 0804a000 rw-p 00000000 03:03 439029                               /home/mm/src/example

……………

bfffe000 – c0000000 rwxp ffff000 00:00 0

———————————————————————————————————————-

每行数据格式如下:

(内存区域)开始-结束 访问权限  偏移  主设备号:次设备号 i节点  文件。

注意,你一定会发现进程空间只包含三个内存区域,似乎没有上面所提到的堆、bss等,其实并非如此,程序内存段和进程地址空间中的内存区域是种模糊对应,也就是说,堆、bss、数据段(初始化过的)都在进程空间中由数据段内存区域表示。

Linux内核中对应进程内存区域的数据结构是: vm_area_struct, 内核将每个内存区域作为一个单独的内存对象管理,相应的操作也都一致。采用面向对象方法使VMA结构体可以代表多种类型的内存区域--比如内存映射文件或进程的用户空间栈等,对这些区域的操作也都不尽相同。

vm_area_strcut结构比较复杂,关于它的详细结构请参阅相关资料。我们这里只对它的组织方法做一点补充说明。vm_area_struct是描述进程地址空间的基本管理单元,对于一个进程来说往往需要多个内存区域来描述它的虚拟空间,如何关联这些不同的内存区域呢?大家可能都会想到使用链表,的确vm_area_struct结 构确实是以链表形式链接,不过为了方便查找,内核又以红黑树(以前的内核使用平衡树)的形式组织内存区域,以便降低搜索耗时。并存的两种组织形式,并非冗 余:链表用于需要遍历全部节点的时候用,而红黑树适用于在地址空间中定位特定内存区域的时候。内核为了内存区域上的各种不同操作都能获得高性能,所以同时 使用了这两种数据结构。

下图反映了进程地址空间的管理模型:

进程的地址空间对应的描述结构是“内存描述符结构,它表示进程的全部地址空间,——包含了和进程地址空间有关的全部信息,其中当然包含进程的内存区域。

进程内存的分配与回收

创建进程fork()、程序载入execve()、映射文件mmap()、动态内存分配malloc()/brk()等进程相关操作都需要分配内存给进程。不过这时进程申请和获得的还不是实际内存,而是虚拟内存,准确的说是“内存区域”。进程对内存区域的分配最终都会归结到do_mmap()函数上来(brk调用被单独以系统调用实现,不用do_mmap()),

内核使用do_mmap()函数创建一个新的线性地址区间。但是说该函数创建了一个新VMA并不非常准确,因为如果创建的地址区间和一个已经存在的地址区间相邻,并且它们具有相同的访问权限的话,那么两个区间将合并为一个。如果不能合并,那么就确实需要创建一个新的VMA了。但无论哪种情况, do_mmap()函数都会将一个地址区间加入到进程的地址空间中--无论是扩展已存在的内存区域还是创建一个新的区域。

同样,释放一个内存区域应使用函数do_ummap()它会销毁对应的内存区域。

如何由虚变实!

    从上面已经看到进程所能直接操作的地址都为虚拟地址。当进程需要内存时,从内核获得的仅仅是虚拟的内存区域,而不是实际的物理地址,进程并没有获得物理内存(物理页面——页的概念请大家参考硬件基础一章),获得的仅仅是对一个新的线性地址区间的使用权。实际的物理内存只有当进程真的去访问新获取的虚拟地址时,才会由“请求页机制”产生“缺页”异常,从而进入分配实际页面的例程。

该异常是虚拟内存机制赖以存在的基本保证——它会告诉内核去真正为进程分配物理页,并建立对应的页表,这之后虚拟地址才实实在在地映射到了系统的物理内存上。(当然,如果页被换出到磁盘,也会产生缺页异常,不过这时不用再建立页表了)

这种请求页机制把页面的分配推迟到不能再推迟为止,并不急于把所有的事情都一次做完(这种思想有点像设计模式中的代理模式(proxy))。之所以能这么做是利用了内存访问的“局部性原理”,请求页带来的好处是节约了空闲内存,提高了系统的吞吐率。要想更清楚地了解请求页机制,可以看看《深入理解linux内核》一书。

这里我们需要说明在内存区域结构上的nopage操作。当访问的进程虚拟内存并未真正分配页面时,该操作便被调用来分配实际的物理页,并为该页建立页表项。在最后的例子中我们会演示如何使用该方法。

 

 

系统物理内存管理 

虽 然应用程序操作的对象是映射到物理内存之上的虚拟内存,但是处理器直接操作的却是物理内存。所以当应用程序访问一个虚拟地址时,首先必须将虚拟地址转化成 物理地址,然后处理器才能解析地址访问请求。地址的转换工作需要通过查询页表才能完成,概括地讲,地址转换需要将虚拟地址分段,使每段虚地址都作为一个索 引指向页表,而页表项则指向下一级别的页表或者指向最终的物理页面。

每个进程都有自己的页表。进程描述符的pgd域指向的就是进程的页全局目录。下面我们借用《linux设备驱动程序》中的一幅图大致看看进程地址空间到物理页之间的转换关系。

 

 

     上面的过程说起来简单,做起来难呀。因为在虚拟地址映射到页之前必须先分配物理页——也就是说必须先从内核中获取空闲页,并建立页表。下面我们介绍一下内核管理物理内存的机制。

 

物理内存管理(页管理)

Linux内核管理物理内存是通过分页机制实现的,它将整个内存划分成无数个4k(i386体系结构中)大小的页,从而分配和回收内存的基本单位便是内存页了。利用分页管理有助于灵活分配内存地址,因为分配时不必要求必须有大块的连续内存[3],系统可以东一页、西一页的凑出所需要的内存供进程使用。虽然如此,但是实际上系统使用内存时还是倾向于分配连续的内存块,因为分配连续内存时,页表不需要更改,因此能降低TLB的刷新率(频繁刷新会在很大程度上降低访问速度)。

鉴于上述需求,内核分配物理页面时为了尽量减少不连续情况,采用了“伙伴”关系来管理空闲页面。伙伴关系分配算法大家应该不陌生——几乎所有操作系统方面的书都会提到,我们不去详细说它了,如果不明白可以参看有关资料。这里只需要大家明白Linux中空闲页面的组织和管理利用了伙伴关系,因此空闲页面分配时也需要遵循伙伴关系,最小单位只能是2的幂倍页面大小。内核中分配空闲页面的基本函数是get_free_page/get_free_pages,它们或是分配单页或是分配指定的页面(248…512页)。

 注意:get_free_page是在内核中分配内存,不同于malloc在用户空间中分配,malloc利用堆动态分配,实际上是调用brk()系统调用,该调用的作用是扩大或缩小进程堆空间(它会修改进程的brk域)。如果现有的内存区域不够容纳堆空间,则会以页面大小的倍数为单位,扩张或收缩对应的内存区域,但brk值并非以页面大小为倍数修改,而是按实际请求修改。因此Malloc在用户空间分配内存可以以字节为单位分配,但内核在内部仍然会是以页为单位分配的。

   另外,需要提及的是,物理页在系统中由页结构struct page描述,系统中所有的页面都存储在数组mem_map[]中,可以通过该数组找到系统中的每一页(空闲或非空闲)。而其中的空闲页面则可由上述提到的以伙伴关系组织的空闲页链表(free_area[MAX_ORDER]索引。

 

文本框: 伙伴关系维护

内核内存使用

Slab

    所 谓尺有所长,寸有所短。以页为最小单位分配内存对于内核管理系统中的物理内存来说的确比较方便,但内核自身最常使用的内存却往往是很小(远远小于一页)的 内存块——比如存放文件描述符、进程描述符、虚拟内存区域描述符等行为所需的内存都不足一页。这些用来存放描述符的内存相比页面而言,就好比是面包屑与面 包。一个整页中可以聚集多个这些小块内存;而且这些小块内存块也和面包屑一样频繁地生成/销毁。

  为了满足内核对这种小内存块的需要,Linux系统采用了一种被称为slab分配器的技术。Slab分配器的实现相当复杂,但原理不难,其核心思想就是“存储池[4]的运用。内存片段(小块内存)被看作对象,当被使用完后,并不直接释放而是被缓存到“存储池”里,留做下次使用,这无疑避免了频繁创建与销毁对象所带来的额外负载。

Slab技术不但避免了内存内部分片(下文将解释)带来的不便(引入Slab分配器的主要目的是为了减少对伙伴系统分配算法的调用次数——频繁分配和回收必然会导致内存碎片——难以找到大块连续的可用内存,而且可以很好地利用硬件缓存提高访问速度。

    Slab并非是脱离伙伴关系而独立存在的一种内存分配方式,slab仍然是建立在页面基础之上,换句话说,Slab将页面(来自于伙伴关系管理的空闲页面链表)撕碎成众多小内存块以供分配,slab中的对象分配和销毁使用kmem_cache_allockmem_cache_free

Kmalloc

Slab分配器不仅仅只用来存放内核专用的结构体,它还被用来处理内核对小块内存的请求。当然鉴于Slab分配器的特点,一般来说内核程序中对小于一页的小块内存的请求才通过Slab分配器提供的接口Kmalloc来完成(虽然它可分配32 131072字节的内存)。从内核内存分配的角度来讲,kmalloc可被看成是get_free_pages)的一个有效补充,内存分配粒度更灵活了。

有兴趣的话,可以到/proc/slabinfo中找到内核执行现场使用的各种slab信息统计,其中你会看到系统中所有slab的使用信息。从信息中可以看到系统中除了专用结构体使用的slab外,还存在大量为Kmalloc而准备的Slab(其中有些为dma准备的)。

 

 

内核非连续内存分配(Vmalloc

 

伙伴关系也好、slab技 术也好,从内存管理理论角度而言目的基本是一致的,它们都是为了防止“分片”,不过分片又分为外部分片和内部分片之说,所谓内部分片是说系统为了满足一小 段内存区(连续)的需要,不得不分配了一大区域连续内存给它,从而造成了空间浪费;外部分片是指系统虽有足够的内存,但却是分散的碎片,无法满足对大块 “连续内存”的需求。无论何种分片都是系统有效利用内存的障碍。slab分 配器使得一个页面内包含的众多小块内存可独立被分配使用,避免了内部分片,节约了空闲内存。伙伴关系把内存块按大小分组管理,一定程度上减轻了外部分片的 危害,因为页框分配不在盲目,而是按照大小依次有序进行,不过伙伴关系只是减轻了外部分片,但并未彻底消除。你自己比划一下多次分配页面后,空闲内存的剩 余情况吧。

所以避免外部分片的最终思路还是落到了如何利用不连续的内存块组合成“看起来很大的内存块”——这里的情况很类似于用户空间分配虚拟内存,内存逻辑上连续,其实映射到并不一定连续的物理内存上。Linux内核借用了这个技术,允许内核程序在内核地址空间中分配虚拟地址,同样也利用页表(内核页表)将虚拟地址映射到分散的内存页上。以此完美地解决了内核内存使用中的外部分片问题。内核提供vmalloc函数分配内核虚拟内存,该函数不同于kmalloc,它可以分配较Kmalloc大得多的内存空间(可远大于128K,但必须是页大小的倍数),但相比Kmalloc来说,Vmalloc需要对内核虚拟地址进行重映射,必须更新内核页表,因此分配效率上要低一些(用空间换时间)

与用户进程相似,内核也有一个名为init_mmmm_strcut结构来描述内核地址空间,其中页表项pdg=swapper_pg_dir包含了系统内核空间(3G-4G)的映射关系。因此vmalloc分配内核虚拟地址必须更新内核页表,而kmallocget_free_page由于分配的连续内存,所以不需要更新内核页表。

文本框: 伙伴关系维护文本框: vmalloc文本框: Kmalloc

vmalloc分配的内核虚拟内存与kmalloc/get_free_page分配的内核虚拟内存位于不同的区间,不会重叠。因为内核虚拟空间被分区管理,各司其职。进程空间地址分布从0到3G(其实是到PAGE_OFFSET, 0×86中它等于0xC0000000),从3Gvmalloc_start这段地址是物理内存映射区域(该区域中包含了内核镜像、物理页面表mem_map等等)比如我使用的系统内存是64M(可以用free看到),那么(3G——3G+64M)这片内存就应该映射到物理内存,而vmalloc_start位置应在3G+64M附近(说"附近"因为是在物理内存映射区与vmalloc_start期间还会存在一个8M大小的gap来防止跃界),vmalloc_end的位置接近4G(说"接近"是因为最后位置系统会保留一片128k大小的区域用于专用页面映射,还有可能会有高端内存映射区,这些都是细节,这里我们不做纠缠)

 

 

上图是内存分布的模糊轮廓

 

   get_free_pageKmalloc函数所分配的连续内存都陷于物理映射区域,所以它们返回的内核虚拟地址和实际物理地址仅仅是相差一个偏移量(PAGE_OFFSET),你可以很方便的将其转化为物理内存地址,同时内核也提供了virt_to_phys()函数将内核虚拟空间中的物理映射区地址转化为物理地址。要知道,物理内存映射区中的地址与内核页表是有序对应的,系统中的每个物理页面都可以找到它对应的内核虚拟地址(在物理内存映射区中的)。

vmalloc分配的地址则限于vmalloc_startvmalloc_end之间。每一块vmalloc分配的内核虚拟内存都对应一个vm_struct结构体(可别和vm_area_struct搞混,那可是进程虚拟内存区域的结构),不同的内核虚拟地址被4k大小的空闲区间隔,以防止越界——见下图)。与进程虚拟地址的特性一样,这些虚拟地址与物理内存没有简单的位移关系,必须通过内核页表才可转换为物理地址或物理页。它们有可能尚未被映射,在发生缺页时才真正分配物理页面。

 

这里给出一个小程序帮助大家认清上面几种分配函数所对应的区域。

#include<linux/module.h>

#include<linux/slab.h>

#include<linux/vmalloc.h>

unsigned char *pagemem;

unsigned char *kmallocmem;

unsigned char *vmallocmem;

int init_module(void)

{

 pagemem = get_free_page(0);

 printk("<1>pagemem=%s",pagemem);

 kmallocmem = kmalloc(100,0);

 printk("<1>kmallocmem=%s",kmallocmem);

 vmallocmem = vmalloc(1000000);

 printk("<1>vmallocmem=%s",vmallocmem);

}

void cleanup_module(void)

{

 free_page(pagemem);

 kfree(kmallocmem);

 vfree(vmallocmem);

}

 

实例

内存映射(mmap)Linux操作系统的一个很大特色,它可以将系统内存映射到一个文件(设备)上,以便可以通过访问文件内容来达到访问内存的目的。这样做的最大好处是提高了内存访问速度,并且可以利用文件系统的接口编程(设备在Linux中 作为特殊文件处理)访问内存,降低了开发难度。许多设备驱动程序便是利用内存映射功能将用户空间的一段地址关联到设备内存上,无论何时,只要内存在分配的 地址范围内进行读写,实际上就是对设备内存的访问。同时对设备文件的访问也等同于对内存区域的访问,也就是说,通过文件操作接口可以访问内存。Linux中的X服务器就是一个利用内存映射达到直接高速访问视频卡内存的例子。

熟悉文件操作的朋友一定会知道file_operations结构中有mmap方法,在用户执行mmap系统调用时,便会调用该方法来通过文件访问内存——不过在调用文件系统mmap方法前,内核还需要处理分配内存区域(vma_struct)、建立页表等工作。对于具体映射细节不作介绍了,需要强调的是,建立页表可以采用remap_page_range方法一次建立起所有映射区的页表,或利用vma_structnopage方法在缺页时现场一页一页的建立页表。第一种方法相比第二种方法简单方便、速度快, 但是灵活性不高。一次调用所有页表便定型了,不适用于那些需要现场建立页表的场合——比如映射区需要扩展或下面我们例子中的情况。

 

我们这里的实例希望利用内存映射,将系统内核中的一部分虚拟内存映射到用户空间,以供应用程序读取——你可利用它进行内核空间到用户空间的大规模信息传输。因此我们将试图写一个虚拟字符设备驱动程序,通过它将系统内核空间映射到用户空间——将内核虚拟内存映射到用户虚拟地址。从上一节已经看到Linux内核空间中包含两种虚拟地址:一种是物理和逻辑都连续的物理内存映射虚拟地址;另一种是逻辑连续但非物理连续的vmalloc分配的内存虚拟地址。我们的例子程序将演示把vmalloc分配的内核虚拟地址映射到用户地址空间的全过程。

程序里主要应解决两个问题:

第一是如何将vmalloc分配的内核虚拟内存正确地转化成物理地址?

因为内存映射先要获得被映射的物理地址,然后才能将其映射到要求的用户虚拟地址上。我们已经看到内核物理内存映射区域中的地址可以被内核函数virt_to_phys转换成实际的物理内存地址,但对于vmalloc分配的内核虚拟地址无法直接转化成物理地址,所以我们必须对这部分虚拟内存格外“照顾”——先将其转化成内核物理内存映射区域中的地址,然后在用virt_to_phys变为物理地址。

转化工作需要进行如下步骤:

a)         找到vmalloc虚拟内存对应的页表,并寻找到对应的页表项。

b)        获取页表项对应的页面指针

c)        通过页面得到对应的内核物理内存映射区域地址

如下图所示:

第二是当访问vmalloc分配区时,如果发现虚拟内存尚未被映射到物理页,则需要处理“缺页异常”。因此需要我们实现内存区域中的nopaga操作,以能返回被映射的物理页面指针,在我们的实例中就是返回上面过程中的内核物理内存映射区域中的地址由于vmalloc分配的虚拟地址与物理地址的对应关系并非分配时就可确定,必须在缺页现场建立页表,因此这里不能使用remap_page_range方法,只能用vmanopage方法一页一页的建立。

 

 

程序组成

map_driver.c,它是以模块形式加载的虚拟字符驱动程序。该驱动负责将一定长的内核虚拟地址(vmalloc分配的)映射到设备文件上。其中主要的函数有——vaddress_to_kaddress()负责对vmalloc分配的地址进行页表解析,以找到对应的内核物理映射地址(kmalloc分配的地址);map_nopage()负责在进程访问一个当前并不存在的VMA页时,寻找该地址对应的物理页,并返回该页的指针。

test.c 它利用上述驱动模块对应的设备文件在用户空间读取读取内核内存。结果可以看到内核虚拟地址的内容(ok!),被显示在了屏幕上。

 

执行步骤

编译map_driver.cmap_driver.o模块,具体参数见Makefile

加载模块 insmod map_driver.o

生成对应的设备文件

1 /proc/devices下找到map_driver对应的设备命和设备号:grep mapdrv /proc/devices

2 建立设备文件mknod  mapfile c 254 0  (在我的系统里设备号为254

    利用maptest读取mapfile文件,将取自内核的信息打印到屏幕上。

 

全部程序下载 mmap.tar (感谢Martin Frey,该程序的主体出自他的灵感)

 

[1] 静态分配内存就是编译器在编译程序的时候根据源程序来分配内存. 动态分配内存就是在程序编译之后, 运行时调用运行时刻库函数来分配内存的. 静态分配由于是在程序运行之前,所以速度快, 效率高, 但是局限性大. 动态分配在程序运行时执行, 所以速度慢, 但灵活性高.

 

[2]术语"BSS"已经有些年头了,它是block started by symbol的缩写。因为未初始化的变量没有对应的值,所以并不需要存储在可执行对象中。但是因为C标准强制规定未初始化的全局变量要被赋予特殊的默认值(基本上是0),所以内核要从可执行代码装入变量(未赋值的)到内存中,然后将零页映射到该片内存上,于是这些未初始化变量就被赋予了0值。这样做避免了在目标文件中进行显式地初始化,减少空间浪费(来自《Linux内核开发》)

[3] 还有些情况必须要求内存连续,比如DMA传输中使用的内存,由于不涉及页机制所以必须连续分配。

[4] 这种存储池的思想在计算机科学里广泛应用,比如数据库连接池、内存访问池等等。

2008年04月08日
一、概念

物理地址(physical address)
用于内存芯片级的单元寻址,与处理器和CPU连接的地址总线相对应。
——这个概念应该是这几个概念中最好理解的一个,但是值得一提的是,虽然可以直接把物理地址理解成插在机器上那根内存本身,把内存看成一个从0字节一直到最大空量逐字节的编号的大数组,然后把这个数组叫做物理地址,但是事实上,这只是一个硬件提供给软件的抽像,内存的寻址方式并不是这样。所以,说它是“与地址总线相对应”,是更贴切一些,不过抛开对物理内存寻址方式的考虑,直接把物理地址与物理的内存一一对应,也是可以接受的。也许错误的理解更利于形而上的抽像。

虚拟内存(virtual memory)
这是对整个内存(不要与机器上插那条对上号)的抽像描述。它是相对于物理内存来讲的,可以直接理解成“不直实的”,“假的”内存,例如,一个0×08000000内存地址,它并不对就物理地址上那个大数组中0×08000000 – 1那个地址元素;
之所以是这样,是因为现代操作系统都提供了一种内存管理的抽像,即虚拟内存(virtual memory)。进程使用虚拟内存中的地址,由操作系统协助相关硬件,把它“转换”成真正的物理地址。这个“转换”,是所有问题讨论的关键。
有了这样的抽像,一个程序,就可以使用比真实物理地址大得多的地址空间。(拆东墙,补西墙,银行也是这样子做的),甚至多个进程可以使用相同的地址。不奇怪,因为转换后的物理地址并非相同的。
——可以把连接后的程序反编译看一下,发现连接器已经为程序分配了一个地址,例如,要调用某个函数A,代码不是call A,而是call 0×0811111111 ,也就是说,函数A的地址已经被定下来了。没有这样的“转换”,没有虚拟地址的概念,这样做是根本行不通的。
打住了,这个问题再说下去,就收不住了。

逻辑地址(logical address)
Intel为了兼容,将远古时代的段式内存管理方式保留了下来。逻辑地址指的是机器语言指令中,用来指定一个操作数或者是一条指令的地址。以上例,我们说的连接器为A分配的0×08111111这个地址就是逻辑地址。
——不过不好意思,这样说,好像又违背了Intel中段式管理中,对逻辑地址要求,“一个逻辑地址,是由一个段标识符加上一个指定段内相对地址的偏移量,表示为 [段标识符:段内偏移量],也就是说,上例中那个0×08111111,应该表示为[A的代码段标识符: 0x08111111],这样,才完整一些”

线性地址(linear address)或也叫虚拟地址(virtual address)
跟逻辑地址类似,它也是一个不真实的地址,如果逻辑地址是对应的硬件平台段式管理转换前地址的话,那么线性地址则对应了硬件页式内存的转换前地址。

————————————————————-
CPU将一个虚拟内存空间中的地址转换为物理地址,需要进行两步:首先将给定一个逻辑地址(其实是段内偏移量,这个一定要理解!!!),CPU要利用其段式内存管理单元,先将为个逻辑地址转换成一个线程地址,再利用其页式内存管理单元,转换为最终物理地址。

这样做两次转换,的确是非常麻烦而且没有必要的,因为直接可以把线性地址抽像给进程。之所以这样冗余,Intel完全是为了兼容而已。

2、CPU段式内存管理,逻辑地址如何转换为线性地址
一个逻辑地址由两部份组成,段标识符: 段内偏移量。段标识符是由一个16位长的字段组成,称为段选择符。其中前13位是一个索引号。后面3位包含一些硬件细节,如图:

最后两位涉及权限检查,本贴中不包含。

索引号,或者直接理解成数组下标——那它总要对应一个数组吧,它又是什么东东的索引呢?这个东东就是“段描述符(segment descriptor)”,呵呵,段描述符具体地址描述了一个段(对于“段”这个字眼的理解,我是把它想像成,拿了一把刀,把虚拟内存,砍成若干的截—— 段)。这样,很多个段描述符,就组了一个数组,叫“段描述符表”,这样,可以通过段标识符的前13位,直接在段描述符表中找到一个具体的段描述符,这个描述符就描述了一个段,我刚才对段的抽像不太准确,因为看看描述符里面究竟有什么东东——也就是它究竟是如何描述的,就理解段究竟有什么东东了,每一个段描述符由8个字节组成,如下图:

这些东东很复杂,虽然可以利用一个数据结构来定义它,不过,我这里只关心一样,就是Base字段,它描述了一个段的开始位置的线性地址。

Intel设计的本意是,一些全局的段描述符,就放在“全局段描述符表(GDT)”中,一些局部的,例如每个进程自己的,就放在所谓的“局部段描述符表 (LDT)”中。那究竟什么时候该用GDT,什么时候该用LDT呢?这是由段选择符中的T1字段表示的,=0,表示用GDT,=1表示用LDT。

GDT在内存中的地址和大小存放在CPU的gdtr控制寄存器中,而LDT则在ldtr寄存器中。

好多概念,像绕口令一样。这张图看起来要直观些:

首先,给定一个完整的逻辑地址[段选择符:段内偏移地址],
1、看段选择符的T1=0还是1,知道当前要转换是GDT中的段,还是LDT中的段,再根据相应寄存器,得到其地址和大小。我们就有了一个数组了。
2、拿出段选择符中前13位,可以在这个数组中,查找到对应的段描述符,这样,它了Base,即基地址就知道了。
3、把Base + offset,就是要转换的线性地址了。

还是挺简单的,对于软件来讲,原则上就需要把硬件转换所需的信息准备好,就可以让硬件来完成这个转换了。OK,来看看Linux怎么做的。

3、Linux的段式管理
Intel要求两次转换,这样虽说是兼容了,但是却是很冗余,呵呵,没办法,硬件要求这样做了,软件就只能照办,怎么着也得形式主义一样。
另一方面,其它某些硬件平台,没有二次转换的概念,Linux也需要提供一个高层抽像,来提供一个统一的界面。所以,Linux的段式管理,事实上只是“哄骗”了一下硬件而已。

按照Intel的本意,全局的用GDT,每个进程自己的用LDT——不过Linux则对所有的进程都使用了相同的段来对指令和数据寻址。即用户数据段,用 户代码段,对应的,内核中的是内核数据段和内核代码段。这样做没有什么奇怪的,本来就是走形式嘛,像我们写年终总结一样。
include/asm-i386/segment.h

#define GDT_ENTRY_DEFAULT_USER_CS 14
#define __USER_CS (GDT_ENTRY_DEFAULT_USER_CS * 8 + 3)

#define GDT_ENTRY_DEFAULT_USER_DS 15
#define __USER_DS (GDT_ENTRY_DEFAULT_USER_DS * 8 + 3)

#define GDT_ENTRY_KERNEL_BASE 12

#define GDT_ENTRY_KERNEL_CS (GDT_ENTRY_KERNEL_BASE + 0)
#define __KERNEL_CS (GDT_ENTRY_KERNEL_CS * 8)

#define GDT_ENTRY_KERNEL_DS (GDT_ENTRY_KERNEL_BASE + 1)
#define __KERNEL_DS (GDT_ENTRY_KERNEL_DS * 8)

把其中的宏替换成数值,则为:

#define __USER_CS 115        [00000000 1110   0   11]
#define __USER_DS 123        [00000000 1111   0   11]
#define __KERNEL_CS 96    [00000000 1100   0   00]
#define __KERNEL_DS 104 [00000000 1101   0   00]

方括号后是这四个段选择符的16位二制表示,它们的索引号和T1字段值也可以算出来了

__USER_CS              index= 14 T1=0
__USER_DS             index= 15 T1=0
__KERNEL_CS           index=   12   T1=0
__KERNEL_DS           index= 13 T1=0

T1均为0,则表示都使用了GDT,再来看初始化GDT的内容中相应的12-15项(arch/i386/head.S):

.quad 0×00cf9a000000ffff /* 0×60 kernel 4GB code at 0×00000000 */
.quad 0×00cf92000000ffff /* 0×68 kernel 4GB data at 0×00000000 */
.quad 0×00cffa000000ffff /* 0×73 user 4GB code at 0×00000000 */
.quad 0×00cff2000000ffff /* 0×7b user 4GB data at 0×00000000 */

按照前面段描述符表中的描述,可以把它们展开,发现其16-31位全为0,即四个段的基地址全为0。

这样,给定一个段内偏移地址,按照前面转换公式,0 + 段内偏移,转换为线性地址,可以得出重要的结论,“在Linux下,逻辑地址与线性地址总是一致(是一致,不是有些人说的相同)的,即逻辑地址的偏移量字段的值与线性地址的值总是相同的。!!!”

忽略了太多的细节,例如段的权限检查。呵呵。

Linux中,绝大部份进程并不例用LDT,除非使用Wine ,仿真Windows程序的时候。

4.CPU的页式内存管理

CPU的页式内存管理单元,负责把一个线性地址,最终翻译为一个物理地址。从管理和效率的角度出发,线性地址被分为以固定长度为单位的组,称为页 (page),例如一个32位的机器,线性地址最大可为4G,可以用4KB为一个页来划分,这页,整个线性地址就被划分为一个tatol_page [2^20]的大数组,共有2的20个次方个页。这个大数组我们称之为页目录。目录中的每一个目录项,就是一个地址——对应的页的地址。

另一类“页”,我们称之为物理页,或者是页框、页桢的。是分页单元把所有的物理内存也划分为固定长度的管理单位,它的长度一般与内存页是一一对应的。

这里注意到,这个total_page数组有2^20个成员,每个成员是一个地址(32位机,一个地址也就是4字节),那么要单单要表示这么一个数组,就要占去4MB的内存空间。为了节省空间,引入了一个二级管理模式的机器来组织分页单元。文字描述太累,看图直观一些:

如上图,
1、分页单元中,页目录是唯一的,它的地址放在CPU的cr3寄存器中,是进行地址转换的开始点。万里长征就从此长始了。
2、每一个活动的进程,因为都有其独立的对应的虚似内存(页目录也是唯一的),那么它也对应了一个独立的页目录地址。——运行一个进程,需要将它的页目录地址放到cr3寄存器中,将别个的保存下来。
3、每一个32位的线性地址被划分为三部份,面目录索引(10位):页表索引(10位):偏移(12位)
依据以下步骤进行转换:
1、从cr3中取出进程的页目录地址(操作系统负责在调度进程的时候,把这个地址装入对应寄存器);
2、根据线性地址前十位,在数组中,找到对应的索引项,因为引入了二级管理模式,页目录中的项,不再是页的地址,而是一个页表的地址。(又引入了一个数组),页的地址被放到页表中去了。
3、根据线性地址的中间十位,在页表(也是数组)中找到页的起始地址;
4、将页的起始地址与线性地址中最后12位相加,得到最终我们想要的葫芦;

这个转换过程,应该说还是非常简单地。全部由硬件完成,虽然多了一道手续,但是节约了大量的内存,还是值得的。那么再简单地验证一下:
1、这样的二级模式是否仍能够表示4G的地址;
页目录共有:2^10项,也就是说有这么多个页表
每个目表对应了:2^10页;
每个页中可寻址:2^12个字节。
还是2^32 = 4GB

2、这样的二级模式是否真的节约了空间;
也就是算一下页目录项和页表项共占空间 (2^10 * 4 + 2 ^10 *4) = 8KB。哎,……怎么说呢!!!

红色错误,标注一下,后文贴中有此讨论。。。。。。

值得一提的是,虽然页目录和页表中的项,都是4个字节,32位,但是它们都只用高20位,低12位屏蔽为0——把页表的低12屏蔽为0,是很好理解的,因为这样,它刚好和一个页面大小对应起来,大家都成整数增加。计算起来就方便多了。但是,为什么同时也要把页目录低12位屏蔽掉呢?因为按同样的道理,只要屏蔽其低10位就可以了,不过我想,因为12>10,这样,可以让页目录和页表使用相同的数据结构,方便。

本贴只介绍一般性转换的原理,扩展分页、页的保护机制、PAE模式的分页这些麻烦点的东东就不啰嗦了……可以参考其它专业书籍。

5.Linux的页式内存管理
原理上来讲,Linux只需要为每个进程分配好所需数据结构,放到内存中,然后在调度进程的时候,切换寄存器cr3,剩下的就交给硬件来完成了(呵呵,事实上要复杂得多,不过偶只分析最基本的流程)。

前面说了i386的二级页管理架构,不过有些CPU,还有三级,甚至四级架构,Linux为了在更高层次提供抽像,为每个CPU提供统一的界面。提供了一个四层页管理架构,来兼容这些二级、三级、四级管理架构的CPU。这四级分别为:

页全局目录PGD(对应刚才的页目录)
页上级目录PUD(新引进的)
页中间目录PMD(也就新引进的)
页表PT(对应刚才的页表)。

整个转换依据硬件转换原理,只是多了二次数组的索引罢了,如下图:

那么,对于使用二级管理架构32位的硬件,现在又是四级转换了,它们怎么能够协调地工作起来呢?嗯,来看这种情况下,怎么来划分线性地址吧!
从硬件的角度,32位地址被分成了三部份——也就是说,不管理软件怎么做,最终落实到硬件,也只认识这三位老大。
从软件的角度,由于多引入了两部份,,也就是说,共有五部份。——要让二层架构的硬件认识五部份也很容易,在地址划分的时候,将页上级目录和页中间目录的长度设置为0就可以了。
这样,操作系统见到的是五部份,硬件还是按它死板的三部份划分,也不会出错,也就是说大家共建了和谐计算机系统。

这样,虽说是多此一举,但是考虑到64位地址,使用四层转换架构的CPU,我们就不再把中间两个设为0了,这样,软件与硬件再次和谐——抽像就是强大呀!!!

例如,一个逻辑地址已经被转换成了线性地址,0×08147258,换成二制进,也就是:
0000100000 0101000111 001001011000
内核对这个地址进行划分
PGD = 0000100000
PUD = 0
PMD = 0
PT = 0101000111
offset = 001001011000

现在来理解Linux针对硬件的花招,因为硬件根本看不到所谓PUD,PMD,所以,本质上要求PGD索引,直接就对应了PT的地址。而不是再到PUD和 PMD中去查数组(虽然它们两个在线性地址中,长度为0,2^0 =1,也就是说,它们都是有一个数组元素的数组),那么,内核如何合理安排地址呢?
从软件的角度上来讲,因为它的项只有一个,32位,刚好可以存放与PGD中长度一样的地址指针。那么所谓先到PUD,到到PMD中做映射转换,就变成了保持原值不变,一一转手就可以了。这样,就实现了“逻辑上指向一个PUD,再指向一个PDM,但在物理上是直接指向相应的PT的这个抽像,因为硬件根本不知道有PUD、PMD这个东西”。

然后交给硬件,硬件对这个地址进行划分,看到的是:
页目录 = 0000100000
PT = 0101000111
offset = 001001011000
嗯,先根据0000100000(32),在页目录数组中索引,找到其元素中的地址,取其高20位,找到页表的地址,页表的地址是由内核动态分配的,接着,再加一个offset,就是最终的物理地址了。

2008年03月18日
原型定义:


#include <sys/time.h>

int gettimeofday(struct timeval *restrict tp, void  *restrict tzp);

struct timeval {           time_t tv_sec;    /* seconds */           long   tv_usec;   /* microseconds */};
其中tv_usec的变化范围是0~1000,000,每1秒溢出一次。因此可用作一些周期性操作的定时。精度为1us,经测试精度能达到us的级别。

2008年03月17日

Linux是一个多用户的操作系统。每个用户登录系统后,都会有一个专用的运行环境。通常每个用户默认的环境都是相同的,这个默认环境实际上就是一组环境变量的定义。用户可以对自己的运行环境进行定制,其方法就是修改相应的系统环境变量。

常见的环境变量

对于PATH和HOME等环境变量大家都不陌生。除此之外,还有下面一些常见环境变量。

◆ HISTSIZE是指保存历史命令记录的条数。

◆ LOGNAME是指当前用户的登录名。

◆ HOSTNAME是指主机的名称,许多应用程序如果要用到主机名的话,通常是从这个环境变量中来取得的。

◆ SHELL是指当前用户用的是哪种Shell。

◆ LANG/LANGUGE是和语言相关的环境变量,使用多种语言的用户可以修改此环境变量。

◆ MAIL是指当前用户的邮件存放目录。

◆ PS1是基本提示符,对于root用户是#,对于普通用户是$。PS2是附属提示符,默认是“>”。可以通过修改此环境变量来修改当前的命令符,比如下列命令会将提示符修改成字符串“Hello,My NewPrompt :) ”。

# PS1=" Hello,My NewPrompt :) "

Hello,My NewPrompt :)

除了这些常见的环境变量,许多应用程序在安装时也会增加一些环境变量,比如使用Java就要设置JAVA_HOME和CLASSPATH等,而安装五笔输入法会增加环境变量"XMODIFIERS=@im=fcitx"等。

定制环境变量

环境变量是和Shell紧密相关的,用户登录系统后就启动了一个Shell。对于 Linux来说一般是bash,但也可以重新设定或切换到其它的 Shell。环境变量是通过Shell命令来设置的,设置好的环境变量又可以被所有当前用户所运行的程序所使用。对于bash这个Shell程序来说,可 以通过变量名来访问相应的环境变量,通过export来设置环境变量。下面通过几个实例来说明。

1. 显示环境变量HOME

$ echo $HOME

/home/terry

2. 设置一个新的环境变量WELCOME

$ export WELCOME="Hello!"

$ echo $WELCOME

Hello!

3. 使用env命令显示所有的环境变量

$ env

HOSTNAME=terry.mykms.org

PVM_RSH=/usr/bin/rsh

SHELL=/bin/bash

TERM=xterm

HISTSIZE=1000

4. 使用set命令显示所有本地定义的Shell变量

$ set

BASH=/bin/bash

BASH_VERSINFO=([0]="2"[1]="05b"[2]="0"[3]="1"[4]="release"[5]="i386-redhat-linux-gnu")

BASH_VERSION=’2.05b.0(1)-release’

COLORS=/etc/DIR_COLORS.xterm

COLUMNS=80

DIRSTACK=()

DISPLAY=:0.0

5. 使用unset命令来清除环境变量

set可以设置某个环境变量的值。清除环境变量的值用unset命令。如果未指定值,则该变量值将被设为NULL。示例如下:

$ export TEST="Test…" #增加一个环境变量TEST

$ env|grep TEST #此命令有输入,证明环境变量TEST已经存在了

TEST=Test…

$ unset $TEST #删除环境变量TEST

$ env|grep TEST #此命令没有输出,证明环境变量TEST已经存在了

6. 使用readonly命令设置只读变量

如果使用了readonly命令的话,变量就不可以被修改或清除了。示例如下:

$ export TEST="Test…" #增加一个环境变量TEST

$ readonly TEST #将环境变量TEST设为只读

$ unset TEST #会发现此变量不能被删除

-bash: unset: TEST: cannot unset: readonly variable

$ TEST="New" #会发现此也变量不能被修改

-bash: TEST: readonly variable

7. 用C程序来访问和设置环境变量

对于C程序的用户来说,可以使用下列三个函数来设置或访问一个环境变量。

◆ getenv()访问一个环境变量。输入参数是需要访问的变量名字,返回值是一个字符串。如果所访问的环境变量不存在,则会返回NULL。

◆ setenv()在程序里面设置某个环境变量的函数。

◆ unsetenv()清除某个特定的环境变量的函数。

另外,还有一个指针变量environ,它指向的是包含所有的环境变量的一个列表。下面的程序可以打印出当前运行环境里面的所有环境变量:

#include extern char**environ;int main (){char**var;for (var =environ;*var !=NULL;++var)printf ("%s \n ",*var);return 0;}

还可以通过修改一些相关的环境定义文件来修改环境变量,比如对于Red Hat等Linux发行版本,与环境相关的文件有/etc/profile和~/.bashrc等。修改完毕后重新登录一次就生效了。