现在的家用和小型网络产品功能越来越复杂了，会做的却越来越多，成本也不断降低。channel 厂商的选择很多，一个不如意就把你的产品从候选名单中砍掉了，理由往往是你的feature 没什么优势，其实大多数feature 不难做，只是在终端厂商测试的时候测试不过。

所以时时保证代码的稳定可靠很重要，但是feature 每天都会增加，代码每天都在改。linux 系统中的代码在修改的时候很难考虑到对别的模块的影响，不会有多少人会在改完代码之后把整个代码从svn 或者cvs 上checkout 出来再跑一遍。这样的编译错误检查很少有人做，不要说手动去做功能性测试了。

对于这种重复性的工作当然是最好由计算机来做。显然只做编译检查是不够的，那样不能保证功能正确。

要做功能性检查会大大增加自动化测试的难度，对于嵌入式系统，要考虑用什么方法把代码上传到开发板上，用什么方法来配置，用什么测试用例。光光网络产品的拓扑结构就要好好思考一番。因为这些都是自动完成，是不会有人为干预的。

考虑到这些，就不能把测试系统做的太复杂，特别是对于需要两个服务器配合的测试系统，毕竟很长一段时间都不会有人去关心测试系统的状态，等发现有问题要调整的时候，时间已经过去了。

所以自动化测试系统要在功能性和复杂性之间折衷。

记录自己的IT历程，向各位前辈学习！

异常发生的时候，系统会完成一个从用户态到内核态的切换。我们前面提到，对系统某些资源的访问（如CP0等协处理器，Kernel Segment内存），是必须在内核态进行的。因此，如果希望使系统从用户态进入内核态，那么，就必须产生一个异常。
MIPS的异常处理，通常来说，和其他体系结构的异常/中断/陷阱处理，没有太多的区别，总的来说分为三段：
1，保存现场寄存器组（Register File）。在堆栈中开辟一段区域，将32个通用寄存器和CP0的相关寄存器，如Status，BadVaddr，Cause等，保存在这段内存中。其中尤为重要的是EPC，EPC指向引发异常时的指令。
在这个步骤中，首先保存的应该是通用寄存器组，随后是epc/cause/status/badvaddr这几个epc0中的寄存器。从cp0到内存的数据传输必须通过通用寄存器。一般地，编程时的约定是使用k0和k1这两个寄存器暂存。如下例：（适用于32位MIPS模式）

sw zero, 0(sp)
sw at, 4(sp)
sw v0, 8(sp)
...
sw ra, 124(sp) /*先保存通用寄存器组*/
mfc k0, epc
nop /* mfc太慢，要在延迟槽中加一个nop */
sw k0, 128(sp)
mfc k0, cause
nop
sw k0, 132(sp)
...

2，异常处理部分。以Address Error异常为例，当异常发生时，根据保存的BadVaddr，调用两次非对齐加载/存储指令，对内存地址进行数据的读写操作。
3，返回。将保存在堆栈中的寄存器组内容恢复。
从异常状态返回的这个动作，是由硬件完成的。它必须同时完成三个操作：
1，将SR寄存器恢复；2，返回到EPC寄存器所指向的地址继续执行；3，恢复到用户态。如《See MIPS Run》提到的，如果这三个过程没有能够“原子地”执行完毕，那么将会导致一个安全漏洞，用户有可能在某种情况下僭越CPU内核态设定的壁垒，从而非法获得管理员权限。
在MIPS I和MIPS II处理器中，使用rfe这条指令，来进行“从异常中恢复”，也就是恢复SR寄存器，并且将系统从内核态恢复到用户态。但这条指令并没有将执行的指令地址返回到异常发生的指令处。这项工作应当由在此之前的一条JR指令来执行。这样，从异常中返回的相关汇编代码应当为：
mfc k0, epc
jr k0
rfe /* 在上一条jr指令的延迟槽中执行，这样可以保证原子性 */

在MIPS III及以后的处理器中，从异常中返回不再需要这样的繁文缛节，只需要一条eret指令便万事俱备了。

http://sourceforge.net/projects/msuite/
还比较简单，有需求的话，可以做得更复杂。

目前市面上很难买到因特网的路由选择技术这本书了,好不容易弄到个电子版的,与大家共享,感兴趣的朋友可以了解一下

目前市面上很难买到因特网的路由选择技术这本书了,好不容易弄到个电子版的,与大家共享,感兴趣的朋友可以了解一下

目前市面上很难买到因特网的路由选择技术这本书了,好不容易弄到个电子版的,与大家共享,感兴趣的朋友可以了解一下

目前市面上很难买到因特网的路由选择技术这本书了,好不容易弄到个电子版的,与大家共享,感兴趣的朋友可以了解一下

请一段时间学习了BGP,总结了一下,希望与大家交流,共同进步