分类： LINUX
2009-08-02 04:39:41
在去年的LinuxWorld大会上碰到conke.hu（业界的工作狂人），当他介绍他们的开源项目G-bios时，直觉上感到是不错，但看了其过于简要的文档介绍后，并没有兴趣拿来使用。
再次深入了解G-bios,是在浦东软件园的灵感软件公司。
G-bios的设计，分为上下两部分，上半部分短小精悍，以最小的代码量（3.6K）,完成CPU和Memory的初始化，并顺利引导下半部分。
下半部分是一个轻量级的开发环境，也就是说，开发人员无需仿真器，就可以对自己的驱动程序进行开发和调试。之所以能达到如此功效，是因为G-bios的下 半部分实现了基本的子系统，如文件系统（如YAFFS2、JFFS2、CRAMFS、NFS），中断、网络、Flash、USB，当然还实现了Lib库的 主要函数。
在如此开发环境下，只要调用G-bios的API函数，开发和调试驱动程序就可以像在用户态下开发程序一样方便。不仅如此，驱动程序调试也变得简单有效！
设想，如果直接在Linux内核环境下调试驱动程序，因为内核的复杂和牵一发而动全局，因此，调试驱动硬件犹如陷入沼泽地。但是，在G-bios环境下，
因为其轻量，不涉及进程管理，亦不涉及内存管理，只涉及与设备和文件相关的主要东西，因此，对驱动硬件的调试的关注点在设备本身，而非内核代码。
至此，一个疑问会扑面而来，G-bios下开发的驱动程序与kernel下的有何关联？我们所有的辛苦不是为了摘星星而是为了揽月！这就涉及到G-bios的设计思想。
G-bios的设计借鉴了几乎所有主流Bootloader/BIOS的优点（当然避其了U-Boot的缺点），尤其汲取了Linux内核的设计思想，因
此把G-bios下驱动程序移植到Linux
Kernel下，就变得只需套用kernel下驱动程序的框架即可。这是因为在G-bios下调试通了驱动程序的硬件接口，犹如穿越一片森林的重重荆棘，
冲向最后一道关卡kernel，虽说还有距离，但终究只是戴帽子的问题了。
实际上，开发出这样一个与U-boot类似但更胜于U-boot的系统，我们一般人是不太相信的。首先我们会怀疑G-Bios是否是其他开源项目的改写， 其次会对其实效性打上大大的问号。但是，当我看到conke对其代码精益求精的改写过程，再看到他带领大家在G-bios环境下一句句调试复杂网卡 （at91sam926x）驱动程序的过程，到最后，又那么轻易地（当然是对kernel有一定了解的基础上）就把G-bios下的驱动程序移植到 kernel下，所有的质疑都化为感叹。
为了证实G-bios的功能，我翻阅了其源代码。一开始看他编写的代码，尤其是采用的匈牙利命名法，心中有种抵触。因为习惯了Linux kernel代码的风格，主观的认为那种方式就是最好的。可是，在阅读G-bios代码的过程中，当一个个变量在眼前跳出，而在另一个地方看到它时就望名 知其意和类型，有恍然相识的感觉；更有甚者，当一个个短小精悍的函数站在眼前（大多函数的代码都只有十几行或几行），对代码的恐慌从心底消失，取而代之的 是一种喜悦和继续想读下去的愿望。这才感到，当代码编写变为一种艺术时，文字的描述就显得画蛇添足，代码就是最精确的语言（）。