aCoral配套文件系统

Question

aCoral 的文件系统是在ZLG文件系统上经过大量优化改造而来，是面向嵌入式系统的小型文件系统，支持并发访问。它是与FAT12、FAT16 和FAT32 高度兼容的文件系统。支持多种存储介质，如硬盘、软盘、U 盘、SD/MMC 卡、NANDFLASH 等，只要底层驱动提供单块的读写函数即可使用。其设计思想参考了 ZLG/FS 1.0，但是在读写函数和缓冲区管理做了重大改进，使得效率大大提升。
     aCoral的文件系统中大部分底层代码参考了《ARM嵌入式系统软件开发实例（一）》一书。但是由于该书上所实现的文件系统效率极低，而且有好几处bug，所以对其进行大幅度的优化与改进。主要改动如下：
1.   原来的缓冲区管理采用数组的方式，并且缓冲区是一开始就静态分配的。这样导致一方面缓冲区效率极低，而且随着缓冲区的增大，读写速度反而大大降低；另一方面，静态分配缓冲区使得内存浪费严重。
      改写后的缓冲区采用空闲链表+hash查找表的管理方式，并且缓冲区是用malloc动态分配，根据实际需要分配缓冲区，只设置缓冲区个数上限。这样缓冲区的效率大大提高（拷贝大文件，速度提高10倍，一般读写速度提高上百倍），而且内存得到合理的利用。

2.   原来的代码在多任务环境中使用时，需专门创建一个文件服务线程，由文件服务线程进行统一处理文件读写请求。这种方式的缺点是：文件服务线程需要占用一个优先级，而且该优先级不好确定；多一个线程，多一份时间和空间开销；而且文件的读写请求需要通过信号量传递给文件服务线程，导致文件读写请求响应时间增加；安全性低，只要文件服务线程出错，整个文件系统变崩溃。
      改写后代码，通过一个文件系统专有互斥量进行同步，并将读写API全部进行封装，使得该互斥量只在内部使用，防止用户误操作导致死锁，并且避免了原先的所有问题。

3.   原来的底层驱动与文件系统的耦合过紧，不利于以后扩展，导致以后增加新的文件格式和物理设备困难。
      改进后的系统，基于aCoral的驱动模型专门设计了一层底层块设备驱动抽象层，克服了上述缺点，而且在驱动抽象层中加入了块设备物理块大小自适应机制，使得物理块大于512B的设备速度提高。

4.   原来的文件API不够标准，难于记忆
      改进后的API遵从POSIX标准，利于使用，并使得很多其他系统上已有的软件经过很少量的修改就能移植到aCoral上

5.   改进后的文件系统，路径分隔符既支持'/'也支持''，这样兼容性更好。

6.   改进的文件系统修复了原先文件系统中的几处bug

7.   改进后的文件系统的加载/卸载驱动的代码放入文件系统初始化函数中，不需用户程序管理，减少用户出错。并且API改为mount/umount，使得用户一看就知道其功能，而且符合用户使用习惯。

Answer 1

是的，每个核上跑不通操作系统，就相当于是异构多核的情形，我们目前正在做一个arm+dsp的应用，这主要是解决消息传递等通信问题，我们正在考虑用一个中间消息层来解决这个问题。

Answer 2

本帖最后由 cyliu 于 2010-12-25 19:38 编辑

现在操作系统真多啊，支持国产。

本人曾经从事多核安全操作系统研发，使用的是risc指令，一个芯片支持32个核，一个高端开发版可以支持4到8块芯片。

要想利用多核优势,就不能是功能简单堆加,架构设计一定要做好甚至为了某项目标重新设计.本人曾研发的多核操作系统已经完全脱离了linux架构，复杂很多（内核调度流程已经完全是新的，其可以做到每个核上可以跑不同的操作系统，一个业务可以在多核之间作流水线处理，网络系统部分由高速快转发送，当然还要包括不同平面之间的消息传递，。。。。)，不过还是采用了很多Linux的先进思想。

支持你们。