分类目录归档:OS Study

更新sgos2开发文档

具体的构思还没有形成,只是粗略修改了一下开发文档。这次作的最大改动是把进程管理器从内核里移除,这样内核里就剩下ipc、线程管理器和地址空间管理器。不再用bxml作为内核的ipc,具体结构还在构思中。。。一种方式是在内核分配存储空间,另一种方式是在目标线程分配存储空间。

给出doc文档下载地址:


http://sgos.googlecode.com/svn/trunk/sgos2/doc/SGOS2开发文档1.9.doc

重新拿起sgos2

一个学期过去了,也有一个学期没有碰过sgos2的源代码了~~
不过我并不是把sgos2给忘了,偶尔仍在想着如何改进sgos2的内核。

现在,放假了,有点时间了,该写点代码了!

所以,准备,重新拿起,sgos2,继续,未完成的任务!

谢谢,Arthas Lee大牛, ForeverBell神牛等的支持!

sgos2好几个月没有更新

sgos2已经好几个月没有更新了,主要是因为我上大学后太忙了。Endless homework,做不好随时有挂科的危险。虽然还参加了ACM,但是却还没有一天认认真真做过算法的练习题目。而不像某K,可以晚晚写算法,真好。

有不少人都发觉sgos2很久没有更新,其实我一直没有放弃sgos2。只是我比较忙,另外几个参与开发的朋友可能也没多大劲头了。

sgos2的微内核结构还是挺好的。我至少在这几年里不会打算重写sgos,因为觉得它已经很好,稳定、安全、效率就是最好。不过目前面临的问题是,因为每个驱动是独立的进程,进程之间需要高效率的通信,所以我打算,把基于字符串通信的bxml改成只使用几个寄存器传值的快速消息机制。然后如果有必要的话,把bxml的通信弄到用户层实现,通过内存共享进行字符串和二进制数据的传输。这样就可以尽可能把没有必要的内存拷贝省去了。内核里也不需要任何字符串操作,因为字符串操作带来了很多安全问题。之前为了解决字符串和大堆数据传递的安全问题,我甚至还打算在内核里使用try catch的异常处理机制(Linux里有)。

大概到军训或者放寒假之后,或许我就可以再次全身心地投入到sgos2的开发之中。因为在国内对os研究是如此至少让我看到了深入接触它的必要性和未来的发展前景。

《爱在OS前》

转自http://hi.baidu.com/foreverbell_, 有改动!

如果有热心的朋友唱完了下面的歌词,希望能提供mp3,万分感激!

《爱在OS前》

小虾网友颁布了OS大宝典

印在晦涩的chm文件 距今已经ff年

我坐在屏幕前 凝视寄存器的改变

你却在旁静静欣赏我那张憔悴的脸

EAX AX AL AH 是谁的从前

喜欢在MakeFile里寻找只属于我的那代码

经过小虾网友身边

我以成神牛之名许愿 渴望像Flood Fill般蔓延

当古文明只剩下汇编的语言 寄存器成了永垂不朽的诗篇

我给你的爱写在OS前 深埋在VMware的边沿

几十个世纪后出土发现 代码上的注释依然清晰可见

我给你的爱写在OS前 深埋在VMware的边沿

用GCC编译了永远 那已风化千年的文件

一切又重演

EAX AX AL AH 是谁的从前

喜欢在MakeFile里寻找属于我的那画面

经过小虾网友身边

我以成神牛之名许愿 渴望像Flood Fill般蔓延

当古文明只剩下汇编的语言 寄存器成了永垂不朽的诗篇

我给你的爱写在OS前 深埋在VMware的边沿

几十个世纪后出土发现 代码上的注释依然清晰可见

我给你的爱写在OS前 深埋在VMware的边沿

用GCC编译了永远 那已风化千年的文件

一切又重演

我感到很疲倦离0 error还是很远 害怕再也不能回到我的从前

我给你的爱写在OS前 深埋在VMware的边沿

几十个世纪后出土发现 代码上的注释依然清晰可见

我给你的爱写在OS前 深埋在VMware的边沿

用GCC编译了永远 那已风化千年的文件

爱在OS前 爱在OS前

未学会唱歌的我,大胆尝试了高潮的一段。

下载试听

FBOS内核剖析

FB,全名ForeverBell,真实姓名不知。

FB今年在江苏某某中学上初三,写了个操作系统叫FBOS。因为FB是大牛,而且大牛是需要膜拜的,所以我在膜拜的过程中,写下了这个文章来加快膜拜进度。

请点击链接打开《FBOS内核剖析》的文档页面。

链接

在多线程环境下使用局部数组引起的假“内存泄漏”

呼~~~~一直担忧的问题被一个在班上不怎么聪明的我总算解决了……

    昨晚那位网友说了他朋友的一句话,“要彻底搞清楚C语言的原理,必须要深入到指令一层去理解。你写一行C代码,编译器会生成什么样的指令,要做到心中有数。”我当时还是觉得写好程序不一定要把语言的原理研究得那么深啊。看来我错了,正是因为我对我所用的工具的原理没有深刻把握,才会在很多线程的情况下使用大栈空间的,最终导致了好长时间都不能解决的内存占用问题。

    一直担忧的内存泄漏问题,今天晚上心血来潮就计划立即解决掉它,反正过年也是闲着。我本来直觉上认为内存泄漏现象是和我博客插件里使用了以前做得不怎么规范的CPrettyText数据库才发生的。但今晚的实验证明和它没有关系,它也不存在什么内存泄漏的地方。由此也证明我在编写服务器时用的memory内存泄漏检测工具失效的判断是不成立的。问题根源是在多线程的栈空间分配上。

    这是我多年多线程编程以来都没有了解到的问题。

    首先,为了加快服务器的响应速度,我的homeserver并不是采用一般的双线程监听,而是很多个(例如300)来同时工作的,这么多个线程抢着响应,保证了较快的速度。这些线程从开始工作一直到服务器被重启或者关闭时才结束,也就是说在服务器运行过程中不会去主动释放线程资源。

    然后,我在博客插件里使用了几个几百KB大的局部数组变量,由栈空间分配。有的是直接嵌套在函数內,有的是直接嵌套在if之类的结构体中。之所以使用栈空间的原因是不想使用堆空间去分配,在插件中不能用memory内存泄漏检测工具的分配函数。

    当多个线程被调用,同时进入了博客插件中去时,就分配了一定的栈空间,而这些空间又是不能及时回收的,除非结束服务器或者使用其他内存整理工具。所以就导致了虚拟内存一直增大的现象。

    我一开始也不知道是栈空间上的问题。只是今晚用注释法寻找漏洞时,发现就和它相关了。而且,我还尝试使用一个很大的局部变量,例如int t[KB(1000)];这样不断刷新页面,让多个线程进入到博客插件中,结果发现内存占用飞一般地增大!

    同时,我也得到这样一个推论。原来的homeserver的虚拟内存会随着多个线程进入而使栈空间增大从而导致内存占用增大,而这种增大不会一直持续下去。因为工作的线程数目是有限的,当所有的线程都被使用过时,它们的栈空间都达到了各自的极限,就再也不会增大了。

    不知道我的分析是否正确,请大家指点!