Talk for testing setroot

--- title: Talk for testing setroot description: View the slide with "Slide Mode". --- # Testing Setroot  slide: --- ## what we're doing: testing parts of the bootstrap process --- ## Overview of Rumpkernel A Rump Kernel is a lightweight, modular kernel that is designed to allow reutilization of kernel components in different environments, such as userspace and a full operating system, without the need for a full operating system. Rump Kernel is a kernel comprising lone kernel components like drivers, file systems, or network stacks, all usable in isolation or together. This modularity enables the inclusion of only components that developers require, reducing overhead in the process. The design is Microkernel in style. the kernel itself only provides very essential services; other functionalities run in user space. Unmodified Kernel Code: Another prominent feature of Rump Kernels is that they run unmodified NetBSD kernel code. In other words, the thought here is that mature and existing kernel components can be reused without changes in most environments. --- ## Overview of "traditional" rump tests Traditional Rump kernel tests are written by following below steps - Initialization: The RUMP kernel is initialized using functions like rump_init(). This sets up the necessary environment, including memory management, file systems, and other subsystems. - Setting Up the Test Environment: The test sets up the environment required for the specific kernel functionality being tested. For instance, if testing file system operations, a temporary file system might be mounted using rump_sys_mount(). Specific resources, such as directories or files, are created to simulate real-world usage scenarios. - Performing Operations: The core of the test involves performing operations that are being tested. For example, the test might perform file operations like creating, reading, writing, or deleting files to ensure the file system behaves as expected. The RUMP kernel provides wrappers for system calls (e.g., rump_sys_open(), rump_sys_write()) that mimic their real counterparts but operate within the RUMP kernel environment. - Assertions and Validations: Assertions to check the results of the operations. ATF (Automated Test Framework) are used for defining and running these tests, providing macros ATF_REQUIRE() or ATF_REQUIRE_ERRNO() to validate conditions. --- ### Example traditional rump kernel test https://nxr.netbsd.org/xref/src/tests/kernel/t_sysctl.c image goes here --- ### Introduction to ATF The Automated Test Framework, or simply ATF, is a flexible uniform test framework. While it is used by the NetBSD operating system mainly, it isn't limited to that but can be applied to any other software project. Its function is easy creation, running, and reporting of automated tests for the system and kernel components. - Test Cases (ATF_TC): ATF_TC: Represents a single, independent unit of testing. A test case is defined by its name and contains the code to perform the test. ATF_TC_HEAD(tc_name, tc): The header section of a test case, where metadata such as the description (descr) of the test is set. ATF_TC_BODY(tc_name, tc): The body of the test case, where the actual test logic is implemented. This section contains the code that performs the test and checks the results using assertions. ATF_TC_CLEANUP(tc_name, tc) (optional): A cleanup function to be executed after the test body, ensuring that any resources used during the test are properly released. - Test Programs (ATF_TP): ATF_TP_ADD_TCS(tp): A macro that registers all test cases within a test program. This function is responsible for adding each test case to the test program.A test program is a collection of test cases that are logically grouped together. It serves as the entry point when running tests, orchestrating the execution of the individual test cases. - Assertions: ATF_REQUIRE(expression): Asserts that an expression is true. If the expression is false, the test case fails immediately. ATF_REQUIRE_ERRNO(errno, expression): Similar to ATF_REQUIRE, but also checks that the global errno matches the expected value after the expression is evaluated. ATF_CHECK(expression): Like ATF_REQUIRE, but the test continues even if the assertion fails, allowing multiple checks within the same test case ___ ## Challenges faced and their Solution ___ ## Datastructures And Functions to be mocked #### device_t bootdv Argument to setroot(). #### int bootpartition Also argument to setroot() #### ROOT_WAITTIME #### char *bootspec #### TFTPROOT --- ## exposing data structures and functions tftproot_dhcpboot(device_t bootdv) --- ## overview of root device discovery --- ## Protcol between bootloader and kernel: bootinfo entries --- ## some practical examples of test cases --- ## cross compiling on host tests have to be added to makefile and then can be compiled with help of nbmake. binary file is created in object directory. These steps can be done on Host machine. --- ## mounting the obj and src directories with vio9p into the vm --- ## running the tests in the vm from objdir --- ## developing tests --- ## running the tests in the vm from objdir --- --- ## Future work: testing on other architecture