Differences

This shows you the differences between two versions of the page.

--- summerofcode2020projects:kerneldumpregressiontesting [2020/05/14 20:42] – RitikaGupta
+++ summerofcode2020projects:kerneldumpregressiontesting [2020/05/15 01:48] (current) – add CategoryGsoc. MarkLinimon
@@ Line 14: / Line 14: @@
 ===== Deliverables =====
-  * Deliverables for first evaluation:
+  * __**Deliverables for first evaluation**__:
     - A module written in Python which would be able to take Hardware/VM configuration variables and Kernel Dump configuration variables as input and,
       * Generate VM configuration
@@ Line 20: / Line 20: @@
       * Configure kernel dumper
       * Debugging the kernel dump and verifying whether the dump is valid
-  * Deliverables for second evaluation:
+  * __**Deliverables for second evaluation**__:
     - A comprehensive and automated test-suite that will be able to test the kernel dumps generated for a combination of configuration variables, both locally and over a  network.
     - Configure a netdump server on the host machine or a second VM and start dumping over a network
     - Identify the set of test cases to be tested
-  * Deliverables for last evaluation:
+  * __**Deliverables for last evaluation**__:
     - Carry out rigorous testing for every combination of the variables and log out the failures on a separate file.
     - Analyze the code paths which failed
@@ Line 32: / Line 32: @@
 ^ Start ^ End ^ Task ^^
-| 4 May | 1 June | Get ready with my dedicated hardware for the project, interact with the %%FreeBSD%% community and try to get valuable inputs from the community | ✔ |
+| 4 May | 1 June | Get ready with my dedicated hardware for the project, interact with the %%FreeBSD%% community and try to get valuable inputs from the community |  |
 | 1 June | 15 June | Start working on the module and expect it to be utilising bhyve for hosting a VM with necessary specifications |  |
-| 15 June | 29 June | Start using pexpect to interact with the the VM’s console and providing the necessary values for the configuration variables | ✔ |
+| 15 June | 29 June | Start using pexpect to interact with the the VM’s console and providing the necessary values for the configuration variables |  |
-| 29 June | 3 July | Improve the code and check for any backlogs, document everything | ✔ |
+| 29 June | 3 July | Improve the code and check for any backlogs, document everything |  |
-|  |  | **Mid-term Evaluations** | ✔ |
+|  |  | **Phase 1 Evaluation** |  |
-| 3 July | 10 July | Configuring a netdump server on the host machine and start dumping manually over a network | ✔ |
+| 3 July | 10 July | Configuring a netdump server on the host machine and start dumping manually over a network |  |
-| 10 July | 27 July | Bring everything together and be ready with the test suite and ensure that every combination can be tested. Ensure that any failure is logged in a separate log file | ✔ |
+| 10 July | 27 July | Bring everything together and be ready with the test suite and ensure that every combination can be tested. Ensure that any failure is logged in a separate log file |  |
-|  |  | **Phase 2 evaluation** | ✔ |
+|  |  | **Phase 2 Evaluation** |  |
-| 31 July | 24 Aug | Testing phase: Testing different combinations of the configuration variables with the help of atf(7) and kyua(1) and mapping the cases which do not produce a valid dump on primitive testing and log them out in a separate file. Analyzing the cases where the dump produced was not valid. | ✔ |
+| 31 July | 24 Aug | Testing phase: Testing different combinations of the configuration variables with the help of atf(7) and kyua(1) and mapping the cases which do not produce a valid dump on primitive testing and log them out in a separate file. Analyzing the cases where the dump produced was not valid. |  |
-| 24 Aug | 31 Aug | Refine the code to make it more presentable, add final touches to the documentation and prepare to submit the project | ✔ |
+| 24 Aug | 31 Aug | Refine the code to make it more presentable, add final touches to the documentation and prepare to submit the project |  |
-|  |  | **Final evaluation** | ✔ |
+|  |  | **Final Evaluation** |  |
-^ Start ^ End ^ Task ^^
-| 4 May | 1 June | Get ready with my dedicated hardware for the project, interact with the %%FreeBSD%% community and try to get valuable inputs from the community |
-| 1 June | 15 June | Start working on the module and expect it to be utilising bhyve for hosting a VM with necessary specifications |
-| 15 June | 29 June | Start using pexpect to interact with the the VM’s console and providing the necessary values for the configuration variables |
-| 29 June | 3 July | Improve the code and check for any backlogs, document everything |
-|  |  | **Mid-term Evaluations** |
-| 3 July | 10 July | Configuring a netdump server on the host machine and start dumping manually over a network |
-| 10 July | 27 July | Bring everything together and be ready with the test suite and ensure that every combination can be tested. Ensure that any failure is logged in a separate log file |
-|  |  | **Phase 2 evaluation** |
-| 31 July | 24 Aug | Testing phase: Testing different combinations of the configuration variables with the help of atf(7) and kyua(1) and mapping the cases which do not produce a valid dump on primitive testing and log them out in a separate file. Analyzing the cases where the dump produced was not valid. |
-| 24 Aug | 31 Aug | Refine the code to make it more presentable, add final touches to the documentation and prepare to submit the project |
-|  |  | **Final evaluation** |
 ===== Test Plan =====
+  * __**Debugging Kernel Dump**__\\  The **kgdb(1)** utility is a debugger based on gdb that allows debugging of kernel core files.\\  Example -//kgdb /boot/kernel/kernel /var/crash/vmcore.0//\\  Kernel binary - /boot/kernel/kernel\\  Dump path - /var/crash/vmcore.0\\  If it is able to successfully open the dump, the dump is considered to be valid. And then we can backtrace by running “bt” to verify. This method for checking of the kernel dumps is considered sufficient for now. More memory based checks can be added later. The dump can be analyzed either in the VM machine or can be collected at the hsot and be analyzed at the host machine. Analyzing it in the VM seems easier.
+  * __About **atf(7)**__\\  **atf(7)** is an automated testing framework in which tests can be written as shell scripts or as C code. In this project, most of the tests will be written in shell script since the **atf-sh(3)** version is best suited to test the entire application as compared to atf-c, which is mostly used when testing libraries of the kernel based APIs.The test program relies on the **kyua(1)** engine which is responsible for isolation of the test program from the rest of the system and for cleaning the effects of the test program. We can specify it as ''%%atf_set require.user root%%'' in the head function. The man atf-test-case(4) contains a complete list of such options. One of the most useful helper functions provided under **atf(7)** that will be used for checking is the atf-check. It executes a command and analyzes its results, including the exit code, stdout, stderr. This will help us in logging our test results. After the tests have been written, they can be built by creating a Makefile. This creates a Kyuafile in the directory which can be used to run our tests in a deterministic fashion.
 ===== The Code =====
@@ Line 65: / Line 54: @@
 ===== Useful links =====
-(Links to any external resources, work, research etc which may be useful to you or to anybody wanting to understand your work)
+  * [[https://papers.freebsd.org/2019/BSDCan/mihailescu-Migrating_a_bhyve_guest.files/mihailescu-Migrating_a_bhyve_guest.pdf|bhyve]]\\
+  * [[https://pexpect.readthedocs.io/en/stable/|pexpect]]\\
+  * [[https://papers.freebsd.org/2017/vbsdcon/gwydir-The_History_and_Future_of_Crash_Dumps_in_Freebsd.files/gwydir-The_History_and_Future_of_Crash_Dumps_in_Freebsd.pdf|Crash Dumps]]
+----
+{{tag>Gsoc}}