Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1176782
  • 博文数量: 573
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 66
  • 用 户 组: 普通用户
  • 注册时间: 2016-06-28 16:21
文章分类

全部博文(573)

文章存档

2018年(3)

2016年(48)

2015年(522)

分类: LINUX

2016-04-28 10:46:20

文件系统存在的深层次的原因如下:

对于单进程多线程的实时操作系统就不需要文件系统,例如ucos,ecos,因为他们只跑一个程序,当然这个程序有可能有很多功能,但是各个功能的代码都编译到同一个bin中,于是各个功能的代码和数据就是交织在了一起,那么当你修改其中一个时,势必对另外一个带来影响

而对于linux/windows这种多进程的操作系统,必须要有文件系统的支持,
因为他们要可以同时跑多个程序,而且还要使的各个程序能够相互独立(例如更新了其中一个,而又不能影响其他的),那么就必须想办法在存储介质上能够做到相互不干扰,于是就必须让这些不同的程序去占用不同的存储介质空间(各个程序各自占用一段存储介质),那么如何来区分这些不同的存储介质区域呢?
用名字来区分是比较科学和符合人类习惯的,这个名字就是文件名,于是自然就要有文件系统咯



举个例子:
开发一个嵌入式设备,具备的功能如下:1,看图片;2,听音乐
如果用ecos或ucos来做,那么一般来说听音乐专门用一个线程来做,看图片用另外一个线程来做
他们的代码都是编译在同一个工程中,即都是链接在了同一个最终可执行程序中
当你更新其中一个的功能时(例如修改了看图片的功能),例如你仅仅只是加了一句代码,那么势必会对整个可执行程序的memory layout都产生了影响,例如你的这句代码对应的机器码是4字节,那么有可能听音乐的相关代码的地址,就都会往后移动4字节。
ecos/ucos这种实时操作系统,你虽然只是修改了听音乐的代码,但是也对看图片的代码产生了影响,产生这些影响的原因就是这两个功能的实现代码都交织在了同一个可执行程序中
所以对于这种操作系统,你修改了程序,你会重烧整个bin到flash中,而不是只重烧听音乐的功能的部分

而在linux中,我们可以开发两个独立的应用程序,一个用来专门看图片,一个专门用来听音乐
为了克服上述ecos的那种缺陷,就需要想办法把两部分隔离开来,于是就需要在存储的这个层面去进行隔离,于是就需要把flash划分为不同的两个区域,一个区域用来存储看图片的功能的机器码,另外一个区域用来存放听音乐的功能的机器码。只有隔离开之后,才不会造成更改其中一个而导致另一个也被改动的状况。
为了区分这两个区域,需要给予其不同的id,而以名字作为区分是比较符合人类习惯的,于是文件系统就出现了。
说到底,文件系统的本质就是用名字来区分存储介质中的数据。


“linux中一切皆名字”并不是文件系统存在的原因,而是“文件系统”出来之后带来的结果

即便是你用ramfs,那么在linux中也是需要文件系统的,上述说的存储介质不局限于非易失性介质,也包括RAM,所以不管你用什么存储介质,只要是要跑多进程的操作系统,都必须要有文件系统
例如根文件系统使用initramfs,只不过这个ramfs只从flash中读取出来,并解压到内存中的而已。所以这种情况并不能说拷贝到内存之后就不需要文件系统了,文件系统仍然存在,只不过是在内存里了



从RTOS转到linux的人,一般都会有这个疑问,因为搞实时操作系统的人的经验,都是直接烧个bin就可以跑了,以前在8051上跑ucos时那需要什么根文件系统啊,从来没听说过是不!
而直接上来就是做linux的人,也许不会有这个疑问,因为没有对比嘛

上述纯属个人理解,也许有更加本质的原因我没有参透
阅读(1682) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~