我对skyeye的设备模块化的一些想法和实践
现在skyeye对设备的处理方式我觉得比较僵化，我个人认为将对外围设备的支持，在保持原有设备的同时，增加一套设备扩展接口，根据设备的形式制作若干个so文件，在配置文件中设置好，这样就能让skyeye能动态的支持不同的设备，对设备比较了解的人也能比较容易的让skyeye支持新的设备。附件中就是我对这一构想的基本实现，在重新编译后，在配置文件中增加行：
iomod: file, so文件目录名
来让skyeye打开so文件。
而在其后可以跟一行到若干：
iomod: para, 参数key=参数value
作为这个设备模块的参数。
而设备文件的编写可以参照目录中iomod_test.c的模式进行编写。 很好的设计！
王利明和我以前也讨论过让外设仿真更加容易的问题，比如只需在skyeye.conf上配置一些IO参数，然后就可以让skyeye仿真特定配置的额外设硬件了。王利明也做了一些前期的实验，效果很好。
我以前也和大家讨论过让一个开发板仿真形成一个动态连接库或plugin，在target sim时根据读到的skyeye.conf来加载相关文件。
目前没有开展这方面的工作的原因是：skyeye目前还有一些功能在添加，如能耗仿真，ARM9等其它开发板的仿真等，我想等skyeye功能基本增加完，且更加稳定之后，再开展这方面的研究工作。初步定在元旦以后。
而且还要安排人手(必须对skyeye的整体架构很熟悉)做此事.
希望我们能够更加深入地讨论此事！ 怎么一个狂晕了得啊
当时明明在最后还有一段 竟然没了
恩 现在才发现。
不过这些代码中有一部分没涉及到，就是这些设备发生中断irq的方式。我想出的办法是machine_config_t结构中增加一个函数指针，有2个参数标明发生的irq号码和fiq号码，调用这个函数后当前的mach就会发生中断。 斑竹说的有理。
从设计的角度teawater方案还是可以的。
不过，共享库的使用目前是没有必要的。
目前sim部分目标码大约200多K，仅占skyeye（2M）的
大约1/10。这点空间的节省没有必要。
大体上目前skyeye包括所有设备的模拟没有问题。
另外，mem_read_XXX/iomod_do_cycle/...这些函数每个模拟的时钟周期
都要执行，放入共享库，增加了间接调用开销，可能会导致模拟速度的细微降低。 罗翚，好久没有联系了。很抱歉，一直没有把你贡献的gdbserver 公布出来。sorry!!! 主要是为了让其他人不用很仔细的了解skyeye的结构 可以增加对其他设备的模拟 这部分可以作为可选 不选择不运行对模拟速度（现在的情况也不精确啊 呵呵 没看有人谈谈关于执行时钟精确以及能耗模拟的东西啊也）也没影响了 多种选择总没什么坏处
页:
[1]