The advanced design of kernel has made Shaun OS much more stable, attractive. How does it work? I will give a full statement of what i think in my mind, the rule i take when i am coding. First of all, the support of kernel mode thread gives me a great convenience. When hardware’s initialization is done, five kernel mode threads will be created, which i call it ish(interrupt service helper) in code style. These threads are in sleep state by default, but they are waked up by some kernel interrupts, such as keyboard, mouse, network card, and so on. Each kernel thread occupies two pages(8k) memory, including kernel mode stack. I will describe each of it in detail.
- Kernel IO Thread. This thread was created for handle input and output operations made by other kernel components. It uses FIFO algorithm to dispatch every IO request. For example, user made a read() system call to read data from a file , the calling path looks like this, read()->sys_read()->kread()->vfs_read()->ext2_read()->iorequest()->block_read()->ahci_read(), .etc. The iorequest() function will generate an iorequest structure, append it onto io_request_list, then wake up the kernel io thread. The kernel io thread is responsible for fetch data from disk, or other device. It will be blocked and be moved out of kernel run queue if there is no IO request in that list.
- Kernel UI Thread. I create this thread mainly for handle user input(keyboard, mouse) and do redrawing work for each frame when we are in graphic mode. For example, when user moves mouse, the mouse driver generates a mouse movement structure, and wakes up kernel ui thread. The kernel ui thread starts frame redrawing work based on the structure that mouse driver generated. This phase may put into user space in the future, but now , it is in kernel mode. After the redrawing work is done, kernel ui thread will generate a mouse movement message and post it to the correspond user mode thread. User space app use Getmessage() and dispatch_message() to handle this mouse message. A way similar to windows apps.
- Kernel NET Thread. This thread is in sleep state and only be waked up by network card driver. When a packet is received by network card, the card driver will collect incoming data, check mac address, and call ether_input() to put a layer-2 packet in inq list, finally wake up kernel net thread. When the thread is waked up, it gets a packet from inq and parse it, if it is an IP packet sent to a user app, the kernel net thread will transmit this packet to upper level function until the packet is read by user apps.
- Kernel Idle Thread. This thread is the only one in run queue when there is no work to do. typically, it will halt cpu, and do nothing in current version.
- Kernel TIMER Thread. This thread is waked up by timer interrupt handler. If this thread is in active state, it will iterate timer list to see whether a registered timer is expired or not. Kernel supports two types of timer, one-shut timer and periodic timer. Kernel timer thread check each timer registered and call timer callback function if needed.