上一页 1 2 3 4 5 6 7 8 9 ··· 17 下一页
摘要: 遍历目录的主要思想 由于目录就是一颗树,所以遍历目录就转换为遍历一棵树。谈到树的遍历就再熟悉不过了,有树的前序、层次和后序遍历,我使用的是前序遍历,后序遍历和前序遍历本质上一样,而层次遍历要比前两个麻烦些,我两个都实现了,现在贴出来分享下。前序遍历 前序遍历和树的遍历一样,我先显示当前目录的信息,然后遍历目录中的目录项,如果目录项是一个目录则先递归这个子目录,否则如果是目录项是非目录的话就返回。 1 static void DoTraverDir(MyFunc myFunc) 2 { 3 struct stat statBuf; 4 DIR *pDir; 5 str... 阅读全文
posted @ 2014-02-24 11:26 在于思考 阅读(4233) 评论(0) 推荐(2) 编辑
摘要: 前言 目前linux中包含anticipatory、cfq、deadline和noop这4个I/O调度器。2.6.18之前的linux默认使用anticipatory,而之后的默认使用cfq。我们在前面编写简单的ramdisk(有请求队列)中分配请求队列使用了blk_init_queue函数,该函数会默认该请求队列分配一个调度器,这里我们打算不使用该函数默认分配给请求队列的调度器,而是使用noop调度器。noop顾名思义,是一个基本上不干事的调度器。它基本不对请求进行什么附加的处理,仅仅假惺惺地告诉通用块设备层:我处理完了。但与吃空饷的公仆不同,noop的存在还是有不少进步意义的。至少我们现. 阅读全文
posted @ 2014-02-16 21:39 在于思考 阅读(1305) 评论(0) 推荐(1) 编辑
摘要: 前言 前面用无请求队列实现的ramdisk的驱动程序虽然申请了请求队列,但实际上没用上,因为ramdisk不像实际的磁盘访问速度慢需要缓存,ramdisk之间使用内存空间,所以就没用请求队列了。本文将介绍使用请求队列的ramdisk驱动,虽然对于ramdisk使用请求队列用处不大,但对于基于磁盘的块设备驱动来说却是必须要用的。 在LDD3书中,其中的有些块设备操作函数在当前的linux版本中有了很大的变动,需要自己重新根据新定义的一些函数进行适当的移植,以解决编译时报出的各种错误,主要是在请求处理函数中修改。设置请求队列的请求处理函数 在前面用无请求队列实现的ramdisk的驱动程序中直... 阅读全文
posted @ 2014-02-14 21:40 在于思考 阅读(2232) 评论(0) 推荐(1) 编辑
摘要: 快速排序的思想与归并排序思想类似,都是采用分治法的思想。将一个数组A[l...r]使用快速排序可以分解为三个主要的步骤: 通过上面的步骤,我们就可以得到快速排序的一个框架: 从上面的代码中可以看出,分解A数组为左右两个数组是快速排序算法的关键,这个问题本质上为:对数组A中的某个值A[k](k为数组的 阅读全文
posted @ 2014-02-12 16:44 在于思考 阅读(1025) 评论(1) 推荐(1) 编辑
摘要: 归并排序的基本思想是分治法,先将要排序的数组从中间分成两个小的数组,然后分别排序这两个小的数组,最后将这两个小的已经排序的数组合并成一个有序的数组。所以归并排序的基本框架为: 有了上面的框架,归并排序就转换为将两个已经排序的数组合并为一个大的排序数组问题。这个非常简单,只要先比较二个数组的第一个数, 阅读全文
posted @ 2014-02-11 18:48 在于思考 阅读(1027) 评论(2) 推荐(0) 编辑
摘要: 最近在研究块设备驱动的编写,看了赵磊大牛的《写一个块设备驱动》,受益匪浅,虽然能看懂里面说的,但动手写写代码还是能加深理解的,下面实现的ramdisk写的很简单,如果有错误,欢迎大牛们指正哈!分配一块内存区存放ramdisk数据 为了简单,我直接静态分配了一个大小为16MB的内存区,当然对于编写驱动来说这个空间有点大。不过就是为了简单嘛,可以理解。#define SIMP_BLKDEV_BYTES (16 * 1024 * 1024)unsigned char simp_blkdev_data[SIMP_BLKDEV_BYTES];分配一个请求队列 可以通过函数b... 阅读全文
posted @ 2014-01-11 11:08 在于思考 阅读(2417) 评论(4) 推荐(1) 编辑
摘要: 1Linux3.10.21内核系统调用设置 以前看的内核版本时2.6.11的,里面的系统调用设置一目了然啊!在文件entry.S中直接定义了sys_call_table表,并在这个文件中用各个系统调用函数的地址初始化了这个表。今天看了下3.10.21的内核,想自己添加个系统调用到这个内核里面,没想到看了半天还是在云里雾里中,只知道sys_call_table表的定义在文件/usr/src/linux-3.10/arch/x86/kernel/syscall_32.c中,当具体怎么初始化这个表的还是不知道。找了半天都没找到表sys_call_table初始化的地方,后来回到syscall_32. 阅读全文
posted @ 2013-12-24 16:45 在于思考 阅读(3377) 评论(0) 推荐(0) 编辑
摘要: 为什么要使用动态链接? 在现代的linux系统中,假设一个普通的程序会使用到c语言静态库至少1MB以上,那么,如果我们的机器运行100个这样的程序,就用浪费近100MB的内存;如果磁盘有2000个这样的程序,就要浪费2GB的内存。 静态链接对程序的更新、发布等也会带来问题。比如程序program1使 阅读全文
posted @ 2013-12-19 15:58 在于思考 阅读(1408) 评论(0) 推荐(0) 编辑
摘要: 链接器在根据命令行中输入的可重定位目标文件和静态库的顺序从左到右的扫描这些文件。在这个扫描中,链接器会维护一个集合E,该集合包含了将来要被合并生产可执行文件的所有可重定位目标文件;维护了一个集合U,包含了未解决的符号(只引用了但还没有定义);还维护了一个集合D,包含被先前输入文件定义的符号。开始的时候这三个集合都为空。对于在命令行中的每个输入文件f,链接器都会去判断这个文件是目标文件还是静态库文件。如果是目标文件,链接器将f加入到集合E中,并将f中的已定义的符号和引用的符号分别加入到集合D和U中,并继续处理下一个文件。如果f是静态库文件,链接器会扫描静态库中的目标文件m,如果m中定义的符号.. 阅读全文
posted @ 2013-12-19 10:20 在于思考 阅读(881) 评论(0) 推荐(0) 编辑
摘要: 一直对ELF目标文件是怎样链接成可执行文件感到比较的疑惑,ELF文件里面的重定位段是怎样解决符号引用问题的?前几天偶然看了《深入理解计算机系统》里面讲了这个问题,看了之后对里面的实现机制终于有了一定的理解。 当有链接器链接多个可重定位的共享对象时,共享对象时怎样合并的呢?很简单,链接器将相同类型的节合并在一起,比如将所有输入文件的.text合并到输出文件的.text段,接着是.data段,.bss段等。 链接器扫描所有的输入目标文件,并且获得它们各个节的长度,属性和位置,并将输入目标文件中的符号表中所有的符号定义和符号引用收集起来,统一放到一个全局符号表中。链接器能够获得所有输入目标文... 阅读全文
posted @ 2013-12-18 11:18 在于思考 阅读(1961) 评论(0) 推荐(1) 编辑
上一页 1 2 3 4 5 6 7 8 9 ··· 17 下一页