[Fault-injection-developer] FITH code coverage test for e100 driver result.

[Gao, K. <kev...@in...>]

Now FITH can inject fault while driver reads/writes the
special IO/MMIO. After analysis e100 specification, we make
many test case for e100. These test cases may help e100 run
some exception branch, which will hardly be runned.

Now the codecoverage test for e100 test cases is as follow:
(The percent of runned code is less is becuase the result 
does not include all the code of driver uninitialization.
And most ioctl operations are not tested.)

The percent of codecoverage (Driver without FI): 
e100_main.c            54.96%
e100_phy.c             44.11%
e100_config.c          45.28%
e100_eeprom.c          51.81%

The percent of codecoverage (Driver with FI):
e100_main.c            57.81%
e100_phy.c             46.62%
e100_config.c          45.28%
e100_eeprom.c          51.81%

The progress we made:
e100_main.c            2.85%    46 lines.
e100_phy.c             2.51%    10 lines.

The advantage of FITH for code coverage:
    1. FITH can simulate hardware fault while driver reads or
	writes the special IO, MMIO of the device. If the branch checks
	hardware status or data in IO/MMIO, FITH always can intercept 
	it and changes it. (example as follow).

		status = readw(port);	//We can change here.
		if (status & BIT2) {
			...
		}
		else {
			..
		}
	
        2. We can print information to kernel message by FITH, so that when
	the the turn of the driver operation is complex, with the great
information
	we get, we can also make test cases for it.

The disadvantage of FITH for code coverage:
	Driver always use some private struct and data to record some
	flags, so that based on it, driver will decide how to do. About the
branch
	of these branches, inject fault is difficult, just because FITH
cannot
	track the private data of driver. (example as follow)
			
		
		if (private->flags & FL_OK) { 	//We cannot track private.
			...
		}
		else {
			...
		}