The discussion and official page of the club are on the Facebook: https://www.facebook.com/groups/224024274384934/
Before going to the U.S, I was the co-founder of the JuluOSDev clud, which focuses on discussion of so many different system software, FreeBSD, RTOS, Microckernel, Nanokernel, Exokernel, Virtualization and IoT systems. When I co-founded the JuluOSDev, there were only 7 members; however, after core members' effort, the group has been expanded to 700+ members now. It was the wonderful experience because we knew a lot of OS contributors in Taiwan via the talk invitations and knowledge sharing.
Although I am not the co-founder now, I still hope this group can keep expanding in order to leave the space for us to discussion about different system software instead of only major OS, Linux.
Keep Coding, Keep Learning.
Life is my implementation
Thursday, November 23, 2017
Wednesday, April 12, 2017
[Systematical Case Study] Zephyr Inside Shell
Overview: File Usages |
Whole Article:
https://github.com/HawxChen/Thoughts-Technical_Readings/blob/master/Zephyr_CaseStudy.pdf
Keywords: Interrupt, ISR, UART Driver, console driver, ISR, IDT, Callback.
Abstract
This case study comprehensively surveys zephyr through understanding of shell’s internal implementation. It includes shell functions, console driver, UART driver, ISR set-up, hardware configuration, system initialization, and related IDT mechansims.
Motivation
To understand the interactivities between task, fiber, driver, interrupts and hardware, case study of Shell implementation is representative. It contains prompt, console driver, UART driver, and related hardware configurations. When I was programming the final assignment, due to my adoption of the Nanokernel, I must ensure that it is achievable to use shell, task, and fibers without related scheduling problems. Through examination of shell implementation, I understood how Zephyr works.
Labels:
Design Topic,
driver,
Kernel,
RTOS,
TRACE
Thursday, November 17, 2016
[Sample Code] Write a mprobe module for dynamic debugging.
Kernel debugging is generally viewed as an annoying process because it might heavily use printk with static debugging techniques (compile, then run). However, in this work, I want to show you how to write a mprobe module through device interface and then, in user programs, we can use POSIX interface, open()/read()/write(), to operate the virtual device exported through the mprobe module. Through this virtual device, we can observe the interesting kernel information. Therefore, without any help from physical devices, we can dynamically debug developing kernel modules.
In this work, I demonstrated how to write a loadable kernel module and a mprobe module; moreover, the kernel module can be debugged by the mprobe module.
- https://github.com/HawxChen/Linux-Kernel-Driver-Programming/tree/master/ASU_CSE530/assignment01
- If you feel it useful, please star or watch this repository.
- A kernel module used hashtable and synchronization.
- A mprobe module could debug the previous kernel module.
- Both parts had testing programs and README.
Subscribe to:
Posts (Atom)