diff --git a/linux-kernel/README.md b/linux-kernel/README.md
new file mode 100644
index 0000000..782a6e8
--- /dev/null
+++ b/linux-kernel/README.md
@@ -0,0 +1,3 @@
+## $\textnormal{Tinkering Linux}$
+
+> - All things I learned related to Linux Kernel.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/01-course-information/01-welcome-to-LFD103.md b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/01-course-information/01-welcome-to-LFD103.md
new file mode 100644
index 0000000..d76704d
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/01-course-information/01-welcome-to-LFD103.md
@@ -0,0 +1,23 @@
+## $\textnormal{Welcome to LFD103}$
+
+> - The `Linux Kernel` is the largest component of the Linux ecosystem,
+ and is charged with managing the hardware, running user programs, and
+ maintaining the security and integrity of the whole system.
+
+> - It is a 24 hour a day, seven days a week, 365 day a year development
+ process that results in a new release once every 9-10 weeks, along
+ with several stable and extended stable releases.
+
+> - At all times, new development and current release integration cycles
+ run in parallel.
+
+> - `LFD103` is designed for anyone interested in becoming a Linux Kernel
+ Developer and contributor.
+
+> - The course aims to ease the Linux Kernel Mentorhship application process.
+
+> - It also serves as a resource for developers from companies and communities
+ that might not be able to take advantage of the mentorship program, and
+ want to learn kernel development on their own; as well as a resource for
+ experienced engineers new to open source and upstream kernel development that
+ are tasked with working with the kernel community.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/01-course-information/02-course-learning-objectives.md b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/01-course-information/02-course-learning-objectives.md
new file mode 100644
index 0000000..2f5b00e
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/01-course-information/02-course-learning-objectives.md
@@ -0,0 +1,16 @@
+## $\textnormal{Course Learning Objectives}$
+
+> - The course will cover the following.
+
+```plaintext
+- Select and configure the development system.
+- Provide an overview of Linux Kernel repositories and releases.
+- Understand git basics - checking out kernel repositories and working with them.
+- Build your first kernel and install it.
+- Understand the Linux Kernel Contributor Covenant Code of Conduct.
+- Familiarize yourself with the Linux Kernel Enforcement Statement.
+- Write kernel patches and test them.
+- Understand the do's and dont's of the communications with the kernel community.
+- Know who to and how to send patches (checkpath.pl and get_maintainers.pl).
+- Re-work patches and act on feedback from reviewers.
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/01-course-information/03-course-audience-and-requirements.md b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/01-course-information/03-course-audience-and-requirements.md
new file mode 100644
index 0000000..f9c606d
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/01-course-information/03-course-audience-and-requirements.md
@@ -0,0 +1,14 @@
+## $\textnormal{Course Audience and Requirements}$
+
+```plaintext
+Audience
+ - This course is designed for individuals interested in becoming Linux Kernel
+ developers and contributors.
+
+Knowledge/Skills
+ - Proficiency in C and shell.
+ - Kernel development experience desired, but not required.
+
+System Prerequisites
+ - As far as prequisites go, an x86_64 laptop will be needed.
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/01-course-information/04-instructor.md b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/01-course-information/04-instructor.md
new file mode 100644
index 0000000..06fb8f3
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/01-course-information/04-instructor.md
@@ -0,0 +1,20 @@
+## $\textnormal{Instructor}$
+
+> - `Shuah Khan` is a Linux Kernel Fellow at The Linux Foundation.
+
+> - She is an experienced Linux Kernel developer, maintainer, and contributor.
+
+> - `Shuah` maintains the Kernel Selftest framework, USB over IP driver, and cpupower,
+ and is an active contributor to the Linux media subsystem.
+
+> - She has also contributed to IOMMU, and DMA areas.
+
+> - In addition, she is helping with stable release kernel testing.
+
+> - She has presented at several Linux conferences and Linux Kernel Developer keynote
+ panels.
+
+> - She served on the Linux Foundataion Technical Advisory Board.
+
+> - She authored Linux Kernel Testing and Debugging paper published in the Linux
+ Journal and wrote several Linux Journal Kernal news articles.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/02-before-you-begin/01-course-support.md b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/02-before-you-begin/01-course-support.md
new file mode 100644
index 0000000..875a166
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/02-before-you-begin/01-course-support.md
@@ -0,0 +1,20 @@
+## $\textnormal{Course Support}$
+> - One great way to interact with peers taking this course is via the Class Forum.
+
+> - Class Forum: https://forum.linuxfoundation.org/categories/lfd103-class-forum
+
+> - The forum can be used in the following ways.
+
+```plaintext
+- To introduce yourself to other peers taking this course.
+
+- To discuss concepts, tools and technologies presented in this course, or related
+ to the topics discussed in the course materials.
+
+- To ask questions or report issues with labs or course content.
+
+- To share resources and ideas related to Linux Kernel development.
+```
+
+> - The class forum will be reviewed periodically by the Linux Foundation staff,
+ but it is primarily a community resource, not an `ask the instructor` service.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/02-before-you-begin/02-course-timing.md b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/02-before-you-begin/02-course-timing.md
new file mode 100644
index 0000000..752ee70
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/02-before-you-begin/02-course-timing.md
@@ -0,0 +1,20 @@
+## $\textnormal{Course Timing}$
+
+> - This course is entirely self-paced; there is no fixed schedule for going
+ through the material. You can go through the course at your own pace,
+ and you will always be returned to exactly where you left off when you
+ come back to start a new session.
+
+> - However, we still suggest you avoid long breaks in between periods of work,
+ as learning will be faster and content retention improved.
+
+> - You have unlimited access to this course for 12 months from the date you
+ registered, even after you have completed the course.
+
+> - The chapters in the course have been designed to build on one another. It
+ is probably best to work through them in sequence; if you skip or only
+ skim some chapters quickly, you may find there are topics being discussed
+ you have not been exposed to yet.
+
+> - But this is all self-paced, and you can always go back, so you can thread
+ your own path through the material.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/02-before-you-begin/03-assessments.md b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/02-before-you-begin/03-assessments.md
new file mode 100644
index 0000000..3914f92
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/02-before-you-begin/03-assessments.md
@@ -0,0 +1,10 @@
+## $\textnormal{Assessments}$
+
+> - While not having lab exercises per se, this course is hands-on, and guides
+ you through the processes involved in Linux Kernel development.
+
+> - At the end of each chapter, you will also find a series of knowledge check
+ questions. These questions, just like the labs, were designed with one main
+ goal in mind: to help you better comprehend the course content and reinforce
+ what you have learned. We would also like to emphasize that you will not be
+ required to take a final exam to complete this course.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/02-before-you-begin/04-course-formatting.md b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/02-before-you-begin/04-course-formatting.md
new file mode 100644
index 0000000..0c2a7d7
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/02-before-you-begin/04-course-formatting.md
@@ -0,0 +1,9 @@
+## $\textnormal{Course Formatting}$
+> - In order to make it easier to distinguish the various types of content
+ in the course, we use the color coding and formats below.
+
+
+
+| Course Formmating |
+| ----------------- |
+|  |
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/02-before-you-begin/05-copyright.md b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/02-before-you-begin/05-copyright.md
new file mode 100644
index 0000000..6f5d276
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/02-before-you-begin/05-copyright.md
@@ -0,0 +1,20 @@
+## $\textnormal{Copyright}$
+
+> - The training materials provided or developed by The Linux Foundation in
+ connection with the training services are protected by copyright and other
+ intellectual property rights.
+
+> - Open source code incorporated herein may have other copyright holders and
+ is used pursuant to the applicable open source license.
+
+> - Although third-party application software packages may be referenced herein,
+ this is for demonstration purposes only and shall not constitute an endorsement
+ of any of these software applications.
+
+> - All the Linux Foundation training, including all the material provided herein,
+ is supplied without any guarantees from the Linux Foundation. The Linux
+ Foundation assumes no liability for damages or legal action arising from the
+ use or misuse of contents or details contained herein.
+
+> - Linux is a registered trademark of Linux Torvalds. Other trademarks within
+ this course material are the property of their respective owners.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/02-before-you-begin/images/image-course-formatting.png b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/02-before-you-begin/images/image-course-formatting.png
new file mode 100644
index 0000000..2979d19
Binary files /dev/null and b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/02-before-you-begin/images/image-course-formatting.png differ
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/03-linux-foundation/01-linux-foundation.md b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/03-linux-foundation/01-linux-foundation.md
new file mode 100644
index 0000000..05caed1
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/03-linux-foundation/01-linux-foundation.md
@@ -0,0 +1,29 @@
+## $\textnormal{Linux Foundation}$
+
+> - `The Linux Foundation` provides a neutral, trusted hub for developers to
+ code, manage, and scale open technology projects.
+
+> - Founded in 2000, the Linux Foundation is supported by more than 1,000
+ members and is the world's leading home for collaboration on open
+ source software, open standards, open data and open hardware.
+
+> - The Linux Foundation's methodology focuses on leveraging best practices
+ and addressing the needs of contributors, users and solution providers to
+ create sustainable models for open collaboration.
+
+> - The Linux Foundation hosts Linux, the world's largest and most pervasive
+ open source software project in history. It is also home to Linux creator
+ Linus Torvalds and lead maintainer Greg Kroah-Hartman.
+
+> - The success of Linux has catalyzed growth in the open source community,
+ demonstrating the commercial efficacy of open source and inspiring
+ countless new projects across all industries and levels of the technology
+ stack.
+
+> - As a result, the Linux Foundation today hosts far more than Linux; it is
+ the umbrella for many critical open source projects that power corporations
+ today, spanning virtually all industry sectors.
+
+> - Some of the technologies we focus on include big data and analytics,
+ networking, embedded systems and IoT, web tools, cloud computing, edge
+ computing, automotive, security, blockchain, and many more.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/03-linux-foundation/02-linux-foundation-events.md b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/03-linux-foundation/02-linux-foundation-events.md
new file mode 100644
index 0000000..3d6d720
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/03-linux-foundation/02-linux-foundation-events.md
@@ -0,0 +1,38 @@
+## $\textnormal{The Linux Foundation Events}$
+
+> - Over 85,000 open source technologists and leaders worldwide gather at Linux
+ Foundation events annually to share ideas, learn and collaborate.
+
+> - Linux Foundation events are the meeting place of choice for open source
+ maintainers, developers, architects, infrastructure managers, and sysadmins
+ and technologists leading open source program offices, and other critical
+ leadership functions.
+
+> - These events are the best place to gain visibility within the open source
+ community quickly and advance open source development work by forming
+ connections with the people evaluating and creating the next generation of
+ technology.
+
+> - They provide a forum to share and gain knowledge, help organizations identify
+ software trends early to inform future technology investments, connect
+ employers with talent, and showcase technologies and services to influential
+ open source professionals, media, and analysts around the globe.
+
+> - The Linux Foundation hosts an increasing number of events each year.
+
+```plaintext
+- Open Source Summit North America, Europe, and Japan.
+- Embbedded Linux Conference North America and Europe.
+- Open Networking and Edge Summit.
+- KubeCon + CloudNativeCon North America, Europe, and China.
+- Automotive Linux Summit.
+- KVM Forum.
+- Linux Storage Filesystem and Memory Management Summit.
+- Linux Security Summit North America and Europe.
+- Linux Kernel Maintainer Summit.
+- The Linux Foundation Member Summit.
+- Open Compliance Summiit.
+- And More.
+
+Link: https://events.linuxfoundation.org/
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/03-linux-foundation/03-training-venues.md b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/03-linux-foundation/03-training-venues.md
new file mode 100644
index 0000000..f098212
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/03-linux-foundation/03-training-venues.md
@@ -0,0 +1,24 @@
+## $\textnormal{Training Venues}$
+
+> - The Linux Foundation's training is for the community, by the community, and
+ features instructors and content straight from the leaders of the Linux
+ Developer community.
+
+> - The Linux Foundation offers several types of training.
+
+```plaintext
+- Classroom
+- Online
+- On-site
+- Events-based
+```
+
+> - Attendees receive Linux and open source software training that is distribution
+ flexible, technically advanced and created with the actual leaders of the Linux
+ and open source software development community themeselves.
+
+> - The Linux Foundation courses give attendees the broad, foundational knowledge and
+ networking needed to thrive in their careers today.
+
+> - With either online or in-person training, the Linux Foundation classes can keep
+ you or your developers ahead of the curve on open source essentials.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/03-linux-foundation/04-linux-foundation-training-offerings.md b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/03-linux-foundation/04-linux-foundation-training-offerings.md
new file mode 100644
index 0000000..3aa2894
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/03-linux-foundation/04-linux-foundation-training-offerings.md
@@ -0,0 +1,11 @@
+## $\textnormal{The Linux Foundation Training Offerings}$
+
+> - Our current course offerings include:
+
+```plaintext
+- Linux programming and development training.
+- Enterprise IT and open source system administration courses.
+- Open source compliance courses.
+
+Link: https://training.linuxfoundation.org/
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/03-linux-foundation/05-linux-foundation-certification.md b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/03-linux-foundation/05-linux-foundation-certification.md
new file mode 100644
index 0000000..faf9768
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/03-linux-foundation/05-linux-foundation-certification.md
@@ -0,0 +1,20 @@
+## $\textnormal{The Linux Foundation Certification}$
+
+> - The Linux Foundation certifications give you a way to diffentiate yourself in a
+ job market that's hungry for your skills.
+
+```plaintext
+https://training.linuxfoundation.org/certification-catalog/
+```
+
+> - We've taken a new innovative approach to open source certification that allows
+ you to showcase your skills in a way that other peers will respect and employers
+ will trust:
+
+```plaintext
+- You can take your certification exam from any computer, anywhere, at any time.
+- The certification exams are either performance-based or multiple choice.
+- The exams are distribution flexible.
+- The exams are up-to-date, testing knowledge and skills that actually matter in today's
+ IT environment.
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/03-linux-foundation/06-training-certification-firewall.md b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/03-linux-foundation/06-training-certification-firewall.md
new file mode 100644
index 0000000..85f1f91
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/01-course-introduction/03-linux-foundation/06-training-certification-firewall.md
@@ -0,0 +1,18 @@
+## $\textnormal{Training Certification Firewall}$
+
+> - The Linux Foundation has two separate training divisions: Course Delivery and Certification.
+ These two divisions are separated by a `firewall`.
+
+> - The curriculum development and maintenance division of the Linux Foundation Training
+ department has no direct role in developing, administering, or grading certification exams.
+
+> - Enforcing this self-imposed firewall ensures that independent organizations and companies
+ can develop third party training material, geared towards helping test takers pass their
+ certification exams.
+
+> - Furthermore, it ensures that there are no secret `tips` (or secrets in general) that one
+ needs to be familiar with in order to succeed.
+
+> - It also permits the Linux Foundation to develop a very robust set of courses that do far more
+ than `teach the test`, but rather equip attendees with a broad knowledge of the many areas
+ they may be required to master to have a successful career in open source system administration.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/01-introduction/01-intro-to-linux-kernel-development.md b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/01-introduction/01-intro-to-linux-kernel-development.md
new file mode 100644
index 0000000..ee36f01
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/01-introduction/01-intro-to-linux-kernel-development.md
@@ -0,0 +1,6 @@
+## $\textnormal{Introduction to Linux Kernel Development Process}$
+
+> - In this chapter, we will provide an overview of the Linux
+ Kernel development process, and we will learn how small
+ incremental changes (`patches`) sent to a mailing list get
+ included in the upstream kernel.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/01-introduction/02-learning-objectives.md b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/01-introduction/02-learning-objectives.md
new file mode 100644
index 0000000..698acc2
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/01-introduction/02-learning-objectives.md
@@ -0,0 +1,10 @@
+## $\textnormal{Learning Objectives}$
+
+> - By the end of this chapter, you should be able to:
+
+```plaintext
+- Understand how the Linux kernel is developed.
+- Discuss the Linux kernel release cycle and merge window.
+- Discuss active kernel releases.
+- Explain the concept of kernel trees.
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/01-about-the-linux-kernel.md b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/01-about-the-linux-kernel.md
new file mode 100644
index 0000000..63de550
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/01-about-the-linux-kernel.md
@@ -0,0 +1,24 @@
+## $\textnormal{About the Linux Kernel}$
+
+
+
+| Tux |
+| --- |
+|  |
+
+
+
+> - The `Linux Kernel` is the result of collaborative development efforts from developers
+ across the globe.
+
+> - Small incremental changes, also known as `patches`, add new features, make
+ enhancements, and fix bugs.
+
+> - It is a 24-hour, seven days a week, and 365 days of continuous development process
+ that results in a new release once every 2+ months, and several stable and extended
+ stable releases once a week. New development and current release integration cycles
+ run in parallel.
+
+> - A new release comes out once a every 10 to 11 weeks. Releases are time-based rather
+ than feature-based. That means releases are not held up for features. There is no
+ set date for these releases.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/02-release-cycle.md b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/02-release-cycle.md
new file mode 100644
index 0000000..9a4b4d2
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/02-release-cycle.md
@@ -0,0 +1,42 @@
+## $\textnormal{What Does the Release Cycle Look Like?}$
+
+> - While the kernel development is a continuous process, at certain points during the
+ development, when a set of features and bug fixes are ready, a new version of the
+ kernel is released.
+
+> - These new version are called `kernel releases`.
+
+> - Linus Torvalds releases a new kernel and opens 2-week merge window.
+
+> - During this merge window, he pulls code for the next release from subsystem
+ maintainers.
+
+> - Subsystem maintainers send signed git pull requests to Linux either during the
+ merge window or before.
+
+> - All major new development is added to the kernel during the merge window.
+
+> - 10,000+ change sets (patches) get pulled into Linus's tree during these 2 weeks,
+ at the end of which he releases the first release candidate, known as `rc1`.
+
+> - At this point, the release cycle moves into a bug fixes-only mode, with a series
+ of `release candidate (rc)` releases from Linus.
+
+> - One week after `rc1` is released, `rc2` comes out; `rc3` comes out a week after,
+ and so on, until all major bug fixes and regressions (if any) are resolved.
+
+> - The new cycle begins with a 3-week `quiet period`, which starts a week before the
+ release, and continues through the 2-week merge window.
+
+> - Maintainers and key contributors are busy getting their trees ready to send pull
+ requests to Linus.
+
+> - Please notee that the quiet period isn't formalized, and each sub-system might
+ handle it differently.
+
+> - This period isn'tt well advertised, and new developers might see a slow response
+ from the community.
+
+| Linux Development Cycle |
+| ----------------------- |
+|  |
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/03-active-kernel-release.md b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/03-active-kernel-release.md
new file mode 100644
index 0000000..7058e1e
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/03-active-kernel-release.md
@@ -0,0 +1,35 @@
+## $\textnormal{Active Kernel Releases}$
+
+```plaintext
+Release Candidate (RC)
+ - Release Candidate or RC releases are mainline kernel pre-releases that are used
+ for testing new features in the mainline.
+ - These releases must be compiled from source.
+ - Kernel developers test these releases for bugs and regressions.
+
+Stable
+ - Stable releases are bug fix-only releases.
+ - After Linus releases a mainline kernel, it moves into stable mode.
+ - Any bug fixes for a stable kernel are backported from the mainline kernel and
+ applied to stable git by a designated stable kernel release maintainer.
+ - Stable kernel updates are released on average, once a week, or on an as needed
+ basis.
+
+Long-term
+ - Long-term releases are stable releases selected for long-term maintenance to
+ provide critical bug fixes for older kernel trees.
+```
+
+> - Stable releases are normally only maintained for a few mainline release cycles,
+ unless they are marked as long-term releases (LTR).
+
+> - A long-term release, as the name suggests, is maintained for a longer period
+ to allow multiple vendors collaborate on a specific kernel release that they
+ plan on maintaining for an extended period of time.
+
+> - You can refer to the `Linux Kernel Archives` for more details about current stable
+ and long-term release, and their release cadence.
+
+```bash
+https://www.kernel.org/category/releases.html
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/04-kernel-trees.md b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/04-kernel-trees.md
new file mode 100644
index 0000000..f36f43a
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/04-kernel-trees.md
@@ -0,0 +1,37 @@
+## $\textnormal{Kernel Trees - What Are They?}$
+
+> - You have probably heard about `kernel trees`; and we have already mentioned the term in
+ previous pages.
+
+> - The kernel code is organized in several main and subsystem git repositories called `trees`.
+
+```plaintext
+Kernel Trees
+ The Mainline Kernel Tree
+ - This tree is maintained by Linus Torvalds.
+ - This is where Linus releases mainline kernels and RC releases.
+
+ The Stable Tree
+ - This tree is maintained by Greg Kroah-Hartman.
+ - This tree consists of stable release branches.
+ - Stable releases are based on this tree.
+
+ The Linux-next Tree
+ - This is the integration tree maintained by Stephen Rothwell.
+ - Code from a large number of subsystem trees gets pulled into this tree periodically
+ and then released for integration testing.
+ - The process of pulling changes from various trees catches merge conflicts (if any)
+ between trees.
+```
+
+> - One of my first actions as a maintainer was to request that my tree be added to
+ linux-next.
+
+> - After I commit patches to my tree, I wait 3 to 7 days before sending a pull request to
+ Linus, giving enough time to find problems and regressions, if any.
+
+> - Patches applied to a tree that will be added to `linux-next` are only for the next merge
+ window, including during the merge window.
+
+> - Patches for the next release may be added to `linux-next` after the merge window has
+ closed, and the `rc1` candidate has been released by Linus.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/05-subsystem-maintainers.md b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/05-subsystem-maintainers.md
new file mode 100644
index 0000000..4462734
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/05-subsystem-maintainers.md
@@ -0,0 +1,58 @@
+## $\textnormal{Subsystem Maintainers}$
+
+> - Each major subsystem has its own tree and designated maintainer(s).
+
+> - Subsystems may have multiple maintainers.
+
+> - You can find a list of subsystem and their maintainers in the `MAINTAINERS file` in the
+ kernel source.
+
+```bash
+https://www.kernel.org/doc/linux/MAINTAINERS
+```
+
+> - In addition, almost every kernel subsystem has a mailing list.
+
+> - Please refer to the `Linux Kernel Mailing Lists` and the `List Archives on lore.kernel.org`
+ for a list of mailing lists and their archives.
+
+```bash
+Linux Kernel Mailing Lists: http://vger.kernel.org/vger-lists.html
+List Archives on lore.kernel.org: https://lore.kernel.org/lists.html
+```
+
+> - Archives are a great reference for patch discussions and history of changes.
+
+> - The development process itself happens entirely over emails.
+
+> - Contributors send patches to mailing lists through email, and contributions are then
+ discussed through emails.
+
+> - Most maintainers send an email response to contributors saying `Applied to tree-name` or
+ `Thanks Applied` to contributors when they accept and commit patches.
+
+> - Some maintainers have a bot that will send patch applied notifications with the patch
+ included in them.
+
+> - Please refer to the `kernel.org git repositories` for a list of kernel trees.
+
+```bash
+kernel.org: https://git.kernel.org/
+```
+
+> - Not all trees are on `kernel.org`.
+
+> - You can find subsystem git information and mailing lists for each of the subsystems in
+ the `MAINTAINERS file`.
+
+> - You can refer to `A guide to the Kernel Development Process` for additional information.
+
+```bash
+Kernel Development Process Guide: https://www.kernel.org/doc/html/latest/process/development-process.html
+```
+
+> - Below is a new developer observed:
+
+| Development Patch Flow |
+| ---------------------- |
+|  |
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/images/image-development-flow.png b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/images/image-development-flow.png
new file mode 100644
index 0000000..985ccff
Binary files /dev/null and b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/images/image-development-flow.png differ
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/images/image-linux-development-cycle.png b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/images/image-linux-development-cycle.png
new file mode 100644
index 0000000..40bdc3f
Binary files /dev/null and b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/images/image-linux-development-cycle.png differ
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/images/image-tux.png b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/images/image-tux.png
new file mode 100644
index 0000000..6fe6522
Binary files /dev/null and b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/02-linux-kernel-development-process/images/image-tux.png differ
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/03-knowledge-check/quiz.md b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/03-knowledge-check/quiz.md
new file mode 100644
index 0000000..540886b
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/02-intro-to-linux-kernel-development/03-knowledge-check/quiz.md
@@ -0,0 +1,27 @@
+## $\textnormal{Quiz}$
+
+```plaintext
+(1) A patch is a small incremental change made to the kernel.
+ - True
+
+(2) The quiet period overlaps with the merge window.
+ - True
+
+(3) How long is the quiet period?
+ - 3 weeks
+
+(4) How many RCs does Linus release before the mainline kernel release?
+ - 7 or 8
+
+(5) The "MAINTAINERS" file has information on who maintains a subsystem.
+ - True
+
+(6) Several kernel git repositories are hosted on.
+ - kernel.org
+
+(7) All patch emails are sent to Linus.
+ - False
+
+(8) New features go into stable releases.
+ - False
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/03-patches/01-introduction/01-introduction-to-patches.md b/linux-kernel/course-Linux-Foundation-LFD103/03-patches/01-introduction/01-introduction-to-patches.md
new file mode 100644
index 0000000..305034b
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/03-patches/01-introduction/01-introduction-to-patches.md
@@ -0,0 +1,10 @@
+## $\textnormal{Introduction to Patches}$
+
+> - You are probably wondering what a change to the kernel looks like.
+
+> - Changes to the kernel are normally called a `patch` after the name of the historical
+ tool that works with incremental changes to a text file, likely originating in the
+ patch used in stitching a quilt or mending a piece of clothing.
+
+> - In this chapter, we will break down the patch into components and talk about the
+ purpose for each one of them.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/03-patches/01-introduction/02-learning-objectives.md b/linux-kernel/course-Linux-Foundation-LFD103/03-patches/01-introduction/02-learning-objectives.md
new file mode 100644
index 0000000..c8e5ecb
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/03-patches/01-introduction/02-learning-objectives.md
@@ -0,0 +1,10 @@
+## $\textnormal{Learning Objectives}$
+
+> - By the end of this chapter, you should be able to:
+
+```plaintext
+- Understand git basics walking through the references.
+- Discuss different patch components.
+- Discuss patch commit logs.
+- Discuss tags.
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/03-patches/02-patches/01-about-patches.md b/linux-kernel/course-Linux-Foundation-LFD103/03-patches/02-patches/01-about-patches.md
new file mode 100644
index 0000000..bccc11c
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/03-patches/02-patches/01-about-patches.md
@@ -0,0 +1,44 @@
+## $\textnormal{About Patches}$
+
+> - Linux kernel development is done using git, which was started by Linus Torvalds
+ and is currently maintained by Junio C. Hamano.
+
+> - To learn more about git, you can read [A short History of Git](https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git) and the [Git Book](https://git-scm.com/book/en/v2) for
+ details on how to use git.
+
+> - The first three chapters of the Git Book provide the basics on how to get commit
+ history, working with remotes, creating branches, tags, and rebasing to tagged
+ versions.
+
+> - These are essential survival skills, necessary for any developer.
+
+> - Developers send changes they want to see in the kernel to the kernel mailing lists
+ through email.
+
+> - These changes are called `patches`.
+
+> - Patches are small incremental changes made to the kernel.
+
+> - Each patch contains a change to the kernel that implements one independent
+ modification that stands on its own.
+
+> - A patch cannot break the kernel build.
+
+> - Requiring each patch to do one thing makes it easier to isolate regressions;
+ reverting a problem patch becomes easier as well.
+
+> - Complex changes to the kernel are thus split into smaller chunks.
+
+> - As an example, if you were to find an existing compile warning while making a
+ code change, you would fix it independently in a separate patch instead of
+ combining it with your code change.
+
+> - Maintainers have their personal preferences on how granular the patch splitting
+ should be for their subsystems.
+
+> - This is true for coding styles as well.
+
+> - Maintainers are good about giving feedback on their preferences during the patch
+ review.
+
+
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/03-patches/02-patches/02-what-is-in-a-patch.md b/linux-kernel/course-Linux-Foundation-LFD103/03-patches/02-patches/02-what-is-in-a-patch.md
new file mode 100644
index 0000000..77ffd50
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/03-patches/02-patches/02-what-is-in-a-patch.md
@@ -0,0 +1,92 @@
+## $\textnormal{What's in a Patch}$
+
+> - You can take a look at a real commit on the next page.
+
+> - In the screenshot we highlighted individual components, and we will walk through
+ these individual components as well. We used:
+
+```bash
+git format-patch -1 --pretty=fuller 3a38e874d70b
+```
+
+> - To generate the patch you will see on the next patch and get the complete
+ information about this patch.
+
+
+
+
+
+
+
+```plaintext
+Patch Components
+ Commit ID
+ - The auto-generated SHA 1 hash is generated from a cryptographic hash function
+ that has all the important information about the patch, such as the commit
+ date, the committer's name and email address, the log message, and more.
+ - Changing any of the information associated with the Commit ID results in
+ changing it.
+ - This makes it a tamperproof fast way to compare two commits using the IDs, and
+ git pull requests become fast and efficient.
+
+ Commit Header
+ "major subsystem: minor area: short description of what is being changed"
+ "usbip: usbip_host: cleanup() do_rebind() return path"
+
+ - As you can see in the image provided above, the patch changes the "usbip_host"
+ driver, which is a sub-driver of the "usbip" driver.
+ - This driver falls under the drivers/usb subsystem.
+ - The author of the patch writes this information in a standard format with ":"
+ separating the major and minor subsystem fields.
+ - You will also see "/" as a separator, which would look like
+ "usbip/usbip_host: cleanup do_rebind() return path" instead of
+ "usbip: usbip_host: cleanup do_rebind() return path".
+ - Using "/" or ":" is determined by the maintainer's preference. If in doubt,
+ refer to a few patches for the subsystem for information on individual preferences.
+
+ Commit Log
+ - It provides a detailed description of the change and why the change is made.
+ - Alternate design choices if any are considered.
+ - Detailed about the testing done.
+ - The example we provided shows a small change and the commit log is simple and to
+ the point.
+ - Commit logs can be long for patches that fix panics, as they include panic stack
+ traces.
+ - We encourage you to take a look at a few commit logs in the kernel source
+ repository to get a better understanding of the kind of information that is relevant
+ to include in them.
+
+ Author
+ - This componennt provides the author's name and email information.
+ - This information can be specified when you run "git commit" or it can be configured
+ in your ".gitconfig" file, which is a very convenient way to generate commits.
+
+ Author Date
+ - Auto-generated commit time and date.
+ - This value comes from the system time of your computer when you create the change.
+
+ Commit
+ - The committer's name and email address.
+ - The committer is a maintainer or developer that applies the patch to a git
+ repository.
+ - This patch was picked up by the USB maitainer Greg Kroah-Hartman and committed to
+ the usb tree and tested prior to being included in a pull request from Greg KH to
+ Linus Torvalds.
+ - Since it was pulled, you won't see Linus as the committer for this patch.
+ - If you look at the git log, you will see several merge commits from Linus for when
+ he pulls subsystem trees from maintainers.
+
+ CommitDate
+ - Auto-generated commit time and date when Greg KH applied this patch to the usb tree.
+ - You will notice that there is a difference of 19 days between the initial commit
+ date and the commit date when the patch was applied to the usb tree.
+ - This is not unusual, depending on where things are in the release cycle.
+ - Merge windows and quiet periods could delay a patch from being applied.
+
+ Signed-off-by
+ - Using sign-off, developers certify the patch to be their original work or have the
+ right to pass it on as an open source patch.
+ - In our example, the author signed off and then, as the usb maintainer, Greg KH
+ signed-off on the patch.
+ - https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/03-patches/02-patches/03-more-about-tags.md b/linux-kernel/course-Linux-Foundation-LFD103/03-patches/02-patches/03-more-about-tags.md
new file mode 100644
index 0000000..c28b420
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/03-patches/02-patches/03-more-about-tags.md
@@ -0,0 +1,28 @@
+## $\textnormal{More About Tags}$
+
+```plaintext
+Acked-by
+ - This tag is often used by the maintainer of the affected code when that maintainer
+ neither contributed to, nor forwarded the patch.
+ - As an example, I maintain the usbip driver and I use the Acked-by tag to ask the
+ USB maintainer to pick patches sent by other developers.
+
+Reviewed-by
+ - This tag indicates that the patch has been reviewed by the person named in the tag.
+
+Reported-by
+ - This tag gives credit to people who find bugs and report them.
+
+Tested-by
+ - This tag indicates that the patch has been tested by the person named in the tag.
+
+Suggested-by
+ - This tag is used to give credit for the patch idea to the person named in the tag.
+
+Fixes
+ - This tag indicates that the patch fixes an issue in a previous commit referenced
+ by its Commit ID.
+ - This tag allows us to track where the bug originated.
+```
+
+> - Reference: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/03-patches/02-patches/04-patch-email-subject-line-conventions.md b/linux-kernel/course-Linux-Foundation-LFD103/03-patches/02-patches/04-patch-email-subject-line-conventions.md
new file mode 100644
index 0000000..b4cf861
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/03-patches/02-patches/04-patch-email-subject-line-conventions.md
@@ -0,0 +1,18 @@
+## $\textnormal{Patch Email Subject Line Conventions}$
+
+> - Last but not least to know is how to prefix patcch email subject lines.
+
+> - The `[PATCH]` prefix is used to indicate that the email consists of a patch.
+
+> - `[PATCH RFC]` or `[RFC PATCH]` indicates the author is requesting comments on the patch.
+
+> - RFC stands for `Request For Comments`.
+
+> - `[PATCH v4]` is used ot indicate that the patch is the 4th version of this specific change
+ that is being submitted.
+
+> - It is not unusual for a patch to go through a few revisions before it gets accepted.
+
+> - This is an artifact of collaborative development.
+
+> - The goal is to get the code right and not rush it in.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/03-patches/02-patches/05-patch-version-history.md b/linux-kernel/course-Linux-Foundation-LFD103/03-patches/02-patches/05-patch-version-history.md
new file mode 100644
index 0000000..b323d84
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/03-patches/02-patches/05-patch-version-history.md
@@ -0,0 +1,23 @@
+## $\textnormal{Patch Version History}$
+
+> - It is a requirement to include the patch version history when sending a re-worked patch.
+
+> - The patch revision history on what changed between the current version and the previous
+ is added between the "---" and the "start of the diff" in the patch file.
+
+> - Any text that is added here thrown away annd will be included in the commit when it is
+ merged into the source tree.
+
+> - It is good practice to include information that helps with reviews and doesn't add value
+ to the commit log here.
+
+> - Please check mailing lists to get a feel for what kind of information gets added here.
+
+> - Do not send new versions of a patch as a reply to a previous version.
+
+> - Start a new thread for each version of a patch.
+
+> - An example description of what changed is: `Changed sicne v3: Added null check for
+ as suggested by .`
+
+> - You see a [patch example with version history for the v2 version.](https://patchwork.kernel.org/project/linux-kselftest/patch/20190926224014.28910-1-skhan@linuxfoundation.org/)
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/03-patches/02-patches/image-patch-commit.png b/linux-kernel/course-Linux-Foundation-LFD103/03-patches/02-patches/image-patch-commit.png
new file mode 100644
index 0000000..0b4edc5
Binary files /dev/null and b/linux-kernel/course-Linux-Foundation-LFD103/03-patches/02-patches/image-patch-commit.png differ
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/04-working-with-the-linux-kernel-community/01-working-with-linux-kernel-community.md b/linux-kernel/course-Linux-Foundation-LFD103/04-working-with-the-linux-kernel-community/01-working-with-linux-kernel-community.md
new file mode 100644
index 0000000..ae061a3
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/04-working-with-the-linux-kernel-community/01-working-with-linux-kernel-community.md
@@ -0,0 +1,37 @@
+## $\textnormal{Linux Kernel Contributor Covenant Code of Conduct}$
+
+> - The Linux Kernel community abides by the `Linux Kernel Contributor Covenant Code of Conduct`.
+
+> - Review the [Contributor Covenant Code of Conduct](https://www.kernel.org/doc/html/latest/process/code-of-conduct.html)
+ and [Linux Kernel COntributor Covenant Code of Conduct Interpretation](https://www.kernel.org/doc/html/latest/process/code-of-conduct-interpretation.html) to understand how to conduct yourself as a contributor and participant in the
+ community.
+
+
+
+
+
+
+## $\textnormal{Linux Enforcement Statement}$
+> - The Linux Kernel is provided under the terms of the GNU General Public License version 2 only
+ (GPL-2.0), as specified in [LICENSES/preferred/GPL-2.0](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/LICENSES/preferred/GPL-2.0), with an explicit syscall exception described in [LICENSES/exceptions/Linux-syscall-note](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/LICENSES/exceptions/Linux-syscall-note),
+ as described in the [COPYING](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/COPYING) file.
+
+> - Please refer to the [Linux Kernel Licensing Rules](https://www.kernel.org/doc/html/latest/process/license-rules.html)
+ for more details.
+
+> - As Linux kernel developers, we have a keen interest in how our software is used and how the license for
+ our software is enforced.
+
+> - We try to balance the enforcement actions with the health and growth of the Linux kernel ecosystem.
+
+> - We formalized our views in the [Linux Kernel Enforcement Statement](https://www.kernel.org/doc/html/latest/process/kernel-enforcement-statement.html).
+
+> - As stated in the above-mentioned enforcement statement.
+
+```plaintext
+The intent is to encourage more use of the software and we want companies and individuals to use,
+modify and distribute this software. We want to work with users in an open and transparent way to
+eliminate any uncertainty about our expectations regarding compliance or enforcement that might
+limit adoption of our software. We view legal action as a last resort, to be initiated only when
+other community efforts have failed to resolve the problem.
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/05-configuring-your-development-system/01-getting-your-system-ready.md b/linux-kernel/course-Linux-Foundation-LFD103/05-configuring-your-development-system/01-getting-your-system-ready.md
new file mode 100644
index 0000000..7d2a242
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/05-configuring-your-development-system/01-getting-your-system-ready.md
@@ -0,0 +1,29 @@
+## $\textnormal{Getting Your System Ready}$
+
+> - On development and test systems, it is a good idea to ensure there is ample space for kernels
+ in the boot partition.
+
+> - Choosing a whole disk install or setting aside 3 GB disk space for the boot partition is
+ recommended.
+
+> - Once the distribution is installed and the system is ready for development packages, enable
+ the root account and also enable sudo for your user account.
+
+> - The system might already have the `build-essential` package, which is what you need to build
+ Linux kernels on an x86-64 system.
+
+> - Recent Ubuntu distributions install a lot of the tools we will need.
+
+```bash
+sudo apt-get install build-essential vim git cscope libncurses-dev libssl-dev bison flex
+sudo apt-get install git-email
+```
+
+> - Once you have a development system, it is time to check if your system supports the [Minimal requirements to compile the Kernel](https://www.kernel.org/doc/html/latest/process/changes.html), these change from time to time.
+
+> - It is a good idea to make sure your system is configured correctly.
+
+> - The next step is finding information on email clients and configuring your email client for
+ sending patches and responding to emails.
+
+> - We highly recommended using `git send-email` for sending patches.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/05-configuring-your-development-system/02-git-email-configuration.md b/linux-kernel/course-Linux-Foundation-LFD103/05-configuring-your-development-system/02-git-email-configuration.md
new file mode 100644
index 0000000..08427d6
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/05-configuring-your-development-system/02-git-email-configuration.md
@@ -0,0 +1,12 @@
+## $\textnormal{Git Email Configuration}$
+
+> - Configuring `git-email` to send patches is easy using the `sendemail` configuration option, once you have
+ your `smtp` server configuration.
+
+> - There is a wealth of online resources for obtaining information on configuring `get sendemail` to send
+ patches.
+
+> - Once you place the above configuration in your `.gitconfig` file, running `git send-email mypatch.patch` is
+ all you have to do to send patches; `mypatch.patch` is generated by the `git format-patch` command.
+
+
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/05-configuring-your-development-system/03-email-client-configuration.md b/linux-kernel/course-Linux-Foundation-LFD103/05-configuring-your-development-system/03-email-client-configuration.md
new file mode 100644
index 0000000..f84154c
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/05-configuring-your-development-system/03-email-client-configuration.md
@@ -0,0 +1,50 @@
+## $\textnormal{Email Client Configuration}$
+
+> - Click this [link](https://trainingportal.linuxfoundation.org/learn/course/a-beginners-guide-to-linux-kernel-development-lfd103/configuring-your-development-system/configuring-your-development-system?page=3).
+
+> - You still have to configure your email client to be able to send responses, to review comments, and
+ other communication with the community.
+
+> - Things to remember:
+
+```plaintext
+Bottom Post
+ - Never top post in your response.
+ - Top posting is writing a message above the original
+ text while sending a response to an email.
+ - Add your response at the bottom of the original text.
+ - Bottom posting makes it easier to read and follow
+ review comments on a patch.
+
+Inline Post
+ - When reviewing or responding to a patch, deleting or
+ stripping parts of the message you are not replying
+ to is a good practice, and makes it easier to follow
+ the responses in the thread.
+
+No HTML Format
+ - Disable compose messages in HTML format.
+ - Patches sent using HTML format will be rejected by
+ the development mailing lists automatically.
+
+No Signatures
+ - Do not include private information in your signature.
+ - This is important for privacy reasons, as you are
+ going to be posting to mailing lists.
+
+No Attachments
+ - Do not send patches as attachments.
+ - In general, avoid attachments. Some exceptions are
+ kernel logs or configuration files when reporting bugs.
+```
+
+> - You should refer to [Email clients info for Linux](https://www.kernel.org/doc/html/latest/process/email-clients.html) for more details.
+
+> - You will have to generate an app-specific password for
+ authentication if you have 2-factor on your Gmail account.
+
+> - Please refer to the Examples in [this document](https://git-scm.com/docs/git-send-email) for more information.
+
+| Example Thunderbird Configuration|
+| -------------------------------- |
+|  |
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/05-configuring-your-development-system/images/01-thunderbird-configuration.png b/linux-kernel/course-Linux-Foundation-LFD103/05-configuring-your-development-system/images/01-thunderbird-configuration.png
new file mode 100644
index 0000000..9c28267
Binary files /dev/null and b/linux-kernel/course-Linux-Foundation-LFD103/05-configuring-your-development-system/images/01-thunderbird-configuration.png differ
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/05-configuring-your-development-system/images/image-email-configuration.png b/linux-kernel/course-Linux-Foundation-LFD103/05-configuring-your-development-system/images/image-email-configuration.png
new file mode 100644
index 0000000..fb656b3
Binary files /dev/null and b/linux-kernel/course-Linux-Foundation-LFD103/05-configuring-your-development-system/images/image-email-configuration.png differ
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/01-linux-mainline.md b/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/01-linux-mainline.md
new file mode 100644
index 0000000..6895cde
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/01-linux-mainline.md
@@ -0,0 +1,19 @@
+## $\textnormal{Linux Mainline}$
+
+> - Latest stable and mainline releases.
+
+```plaintext
+https://www.kernel.org/
+```
+
+> - Linus's tree or mainline.
+
+```plaintext
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
+```
+
+
+
+| Linux Mainline |
+| -------------- |
+|  |
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/02-cloning-the-linux-mainline.md b/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/02-cloning-the-linux-mainline.md
new file mode 100644
index 0000000..c5e2bff
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/02-cloning-the-linux-mainline.md
@@ -0,0 +1,7 @@
+## $\textnormal{Cloning the Linux Mainline}$
+
+```sh
+mkdir linux-work
+cd /linux-work
+git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux-mainline
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/03-root-directory.md b/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/03-root-directory.md
new file mode 100644
index 0000000..48ed397
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/03-root-directory.md
@@ -0,0 +1,17 @@
+## $\textnormal{What is in the Root Directory?}$
+
+> - Cregit linux 5.1 release.
+
+```plaintext
+https://cregit.linuxsources.org/
+https://cregit.linuxsources.org/code/5.1/
+```
+
+
+
+> - The bulk of the kernel code lives under the `drivers` directory.
+
+| Cregit-Linux View of Linux Kernel 5.1 Release |
+| --------------------------------------------- |
+|  |
+
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/04-exploring-sources.md b/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/04-exploring-sources.md
new file mode 100644
index 0000000..694f6aa
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/04-exploring-sources.md
@@ -0,0 +1,24 @@
+## $\textnormal{Exploring the Sources}$
+
+> - Take a look at the `Makefile` and `MAINTAINERS` files in the
+ main directory and `scripts/get_maintainer.pl` and
+ `scripts/checkpatch.pl`.
+
+> - Play with `cregit` or `git log` to look at the history of source
+ files in each of the kernel areas. You can look at individual
+ commits and generate a patch or two using
+
+```sh
+# This will generate a file with the information of the commit.
+git format-patch -1
+
+# Check the information of the file.
+cat
+```
+
+> - You can generate a patch for `a035d552a93bb9ef6048733bb9f2a0dc857ff869`
+ and take a look at the changes made by this commit:
+
+```sh
+git format-patch -1 a035d552a93bb9ef6048733bb9f2a0dc857ff869
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/05-linux-kselftest-repository.md b/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/05-linux-kselftest-repository.md
new file mode 100644
index 0000000..1f9d3fc
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/05-linux-kselftest-repository.md
@@ -0,0 +1,5 @@
+## $\textnormal{Exploring the Linux-KSelfTest Repository}$
+
+| Linux-KSelfTest |
+| --------------- |
+|  |
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/06-quiz.md b/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/06-quiz.md
new file mode 100644
index 0000000..23d4691
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/06-quiz.md
@@ -0,0 +1,15 @@
+## $\textnormal{Knowledge Check}$
+
+```plaintext
+01. Which command would you use to check the history of a source file?
+ Answer: git log
+
+02. Which command would you use to check for 2 recent commits by Linus?
+ Answer: git log -2 --author=Linus
+
+03. Which branch is not present under the linux-kselftest tree?
+ Answer: For-linus
+
+04. Which command is used to switch to a different branch?
+ Answer: git checkout
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/images/01-linus-mainline.png b/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/images/01-linus-mainline.png
new file mode 100644
index 0000000..71b77ff
Binary files /dev/null and b/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/images/01-linus-mainline.png differ
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/images/02-linux-5-1-release.png b/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/images/02-linux-5-1-release.png
new file mode 100644
index 0000000..322f8e3
Binary files /dev/null and b/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/images/02-linux-5-1-release.png differ
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/images/03-linux-kselftest.png b/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/images/03-linux-kselftest.png
new file mode 100644
index 0000000..c6f1a9b
Binary files /dev/null and b/linux-kernel/course-Linux-Foundation-LFD103/06-exploring-linux-kernel-sources/images/03-linux-kselftest.png differ
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/07-building-and-installing-kernel/01-cloning-stable-kernel-git.md b/linux-kernel/course-Linux-Foundation-LFD103/07-building-and-installing-kernel/01-cloning-stable-kernel-git.md
new file mode 100644
index 0000000..c76383e
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/07-building-and-installing-kernel/01-cloning-stable-kernel-git.md
@@ -0,0 +1,27 @@
+## $\textnormal{Cloning the Stable Kernel Git}$
+
+> - The stable repository has several branches going
+ to `linux-2.6.11.y`.
+
+```plaintext
+Latest Stable Release: https://www.kernel.org/
+```
+
+
+
+```sh
+# Clone the stable release.
+git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-stable
+
+# Go to the cloned repository.
+cd linux-stable
+
+# Search using GREP (Global Regular Expression Print).
+git branch -a | grep linux-5
+ remotes/origin/linux-5.12.y
+ remotes/origin/linux-5.11.y
+ remotes/origin/linux-5.10.y
+
+# Check the remote branch.
+git checkout linux-5.12.y
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/07-building-and-installing-kernel/02-copying-configuration.md b/linux-kernel/course-Linux-Foundation-LFD103/07-building-and-installing-kernel/02-copying-configuration.md
new file mode 100644
index 0000000..a1900e1
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/07-building-and-installing-kernel/02-copying-configuration.md
@@ -0,0 +1,33 @@
+## $\textnormal{Copying the Configuration for Current Kernel from /boot}$
+
+> - Starting out with the distribution configuration file is
+ the safest approach for the very first kernel install on
+ any system.
+
+> - You can do so by copying the configuration for your
+ current kernel from `/proc/config.gz` or `/boot`.
+
+> - As an example, I am running `Ubuntu 19.04` and
+ config-5.0.0-21-generic is the configuration I have in
+ `/boot` on my system.
+
+> - Pick the latest configuration you have on your system
+ and copy that to `linux_stable/.config`.
+
+> - In the following example, config-5.0.0-21-generic is the
+ latest kernel configuration.
+
+```sh
+# Check the list of configurations.
+ls /boot
+config-5.0.0-20-generic memtest86+.bin
+config-5.0.0-21-generic memtest86+.elf
+efi memtest86+_multiboot.bin
+grub System.map-5.0.0-20-generic
+initrd.img-5.0.0-20-generic System.map-5.0.0-21-generic
+initrd.img-5.0.0-21-generic vmlinuz-5.0.0-20-generic
+lost+found vmlinuz-5.0.0-21-generic
+
+# Copy the configuration.
+cp /boot/ .config
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/07-building-and-installing-kernel/03-compiling-the-kernel.md b/linux-kernel/course-Linux-Foundation-LFD103/07-building-and-installing-kernel/03-compiling-the-kernel.md
new file mode 100644
index 0000000..86bd454
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/07-building-and-installing-kernel/03-compiling-the-kernel.md
@@ -0,0 +1,42 @@
+## $\textnormal{Compiling the Kernel}$
+
+> - Run the following command to generate a kernel
+ configuration file based on the current configuration.
+
+> - This step is important to configure the kernel,
+ which has a good chance to work correctly on your system.
+
+> - You will be prompted to tune the configuration
+ to enable new features and drivers that have been
+ added since Ubuntu snapshot the kernel from the mainline.
+
+> - `make all` will invoke `make oldconfig` in any case.
+
+> - I am showing these two steps separately just to
+ call out the configuration file generation step.
+
+```sh
+make oldconfig
+```
+
+> - Another way to trim down the kernel and tailor it
+ to your system is by using `make localmodconfig`.
+
+> - This option creates a configuration file based on
+ the list of modules currently loaded on your system.
+
+```sh
+lsmod > /tmp/my-lsmod
+make LSMOD=/tmp/my-lsmod localmodconfig
+```
+
+> - Once this step is complete, it is time to compile the kernel.
+
+> - Using the `-j` option helps the compiles go faster.
+
+> - The `-j` option specifies the number of jobs
+ `(make commands)` to run simultaneously:
+
+```sh
+make -j3 all
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/07-building-and-installing-kernel/04-installing-the-kernel.md b/linux-kernel/course-Linux-Foundation-LFD103/07-building-and-installing-kernel/04-installing-the-kernel.md
new file mode 100644
index 0000000..c79dda0
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/07-building-and-installing-kernel/04-installing-the-kernel.md
@@ -0,0 +1,111 @@
+## $\textnormal{Installing the Kernel}$
+
+> - Once the kernel compilation is complete, install the
+ new kernel.
+
+```sh
+su -c "make modules_install install"
+```
+
+> - The above command will install the new kernel and run
+ `update-grub` to add the new kernel to the grub menu.
+
+> - Now it is time to reboot the system to boot the newly
+ installed kernel.
+
+> - Now it is time to reboot the system to boot the newly
+ installed kernel.
+
+> - Using the `-t` option allows us to generate dmesg logs
+ without the timestamps, and makes it easier to compare
+ the old and the new.
+
+```sh
+dmesg -t > dmesg_current
+dmesg -t -k > dmesg_kernel
+dmesg -t -l emerg > dmesg_current_emerg
+dmesg -t -l alert > dmesg_current_alert
+dmesg -t -l crit > dmesg_current_crit
+dmesg -t -l err > dmesg_current_err
+dmesg -t -l warn > dmesg_current_warn
+dmesg -t -l info > dmesg_current_info
+```
+
+> - In general, `dmesg` should be clean, with no `emerg`, `alert`,
+ `crit`, and `err` level messages.
+
+> - If you see any of these, it might indicate some hardware
+ and/or kernel problem.
+
+> - If the `dmesg_current` is zero length, it is very likely
+ that secure boot is enabled on your system.
+
+> - When secure boot is enabled, you won’t be able to boot
+ the newly installed kernel, as it is unsigned.
+
+> - You can disable secure boot temporarily on startup with MOK manager.
+
+> - Your system should already have `mokutil`.
+
+> - Let's first make sure secure boot is indeed enabled:
+
+```sh
+mokutil --sb-state
+```
+
+> - If you see the following, you are all set to boot your
+ newly installed kernel:
+
+```sh
+SecureBoot disabled
+Platform is in Setup Mode
+```
+
+> - If you see the following, disable secure boot temporarily
+ on startup with MOK manager:
+
+```sh
+SecureBoot enabled
+SecureBoot validation is disabled in shim
+```
+
+> - Disable validation:
+
+```sh
+sudo mokutil --disable-validation
+root password
+mok password: 12345678
+mok password: 12345678
+sudo reboot
+```
+
+> - The machine will reboot in a blue screen, the MOK manager menu.
+
+> - Type the number(s) shown on the screen: if it is 7, it is
+ the 7th character of the password.
+
+> - So, keep 12345678.
+
+> - The question to answer is Yes to disable secure boot. Reboot.
+
+> - You’ll see on startup after a new message (top left) saying
+ `<>`.
+
+> - The machine will boot normally after and secure boot remains enabled.
+
+> - This change is permanent, a clean install won't overwrite it.
+
+> - To re-enable it (please note that you won't be able to boot
+ the kernels you build if you re-enable):
+
+```sh
+sudo mokutil --enable-validation
+root password
+mok password: 12345678
+mok password: 12345678
+sudo reboot
+```
+
+```plaintext
+Reference: https://askubuntu.com/questions/1119734/how-to-replace-or-remove-kernel-with-signed-kernels
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/07-building-and-installing-kernel/05-booting-the-kernel.md b/linux-kernel/course-Linux-Foundation-LFD103/07-building-and-installing-kernel/05-booting-the-kernel.md
new file mode 100644
index 0000000..b796262
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/07-building-and-installing-kernel/05-booting-the-kernel.md
@@ -0,0 +1,60 @@
+## $\textnormal{Booting the Kernel}$
+
+> - There is no guarantee that the new kernel will boot.
+
+> - As a safeguard, we want to make sure that there is
+ at least one good kernel installed and we can select
+ it from the boot menu.
+
+> - By default, grub tries to boot the default kernel,
+ which is the newly installed kernel.
+
+> - We change the default grub configuration file
+ `/etc/default/grub` to the boot menu, and pause for
+
+> - Please note that this option is specific to Ubuntu,
+ and other distributions might have a different way to
+ specify boot menu options.us to be able to select the
+ kernel to boot.
+
+> - Increase the `GRUB_TIMEOUT` value to `10 seconds`, so
+ grub pauses in menu long enough to choose a kernel to boot:
+
+```plaintext
+- Uncomment GRUB_TIMEOUT and set it to 10: GRUB_TIMEOUT=10
+- Comment out GRUB_TIMEOUT_STYLE=hidden
+```
+
+> - If the newly installed kernel fails to boot, it is nice
+ to be able to see the early messages to figure out why
+ the kernel failed to boot.
+
+> - Enable printing early boot messages to vga using the
+ `earlyprintk=vga` kernel boot option:
+
+```sh
+GRUB_CMDLINE_LINUX="earlyprintk=vga"
+```
+
+> - Run `update-grub` to update the grub configuration in `/boot`.
+
+```sh
+sudo update-grub
+```
+
+> - Now, it’s time to restart the system.
+
+> - Once the new kernel comes up, compare the saved `dmesg`
+ from the old kernel with the new one, and see if there
+ are any regressions.
+
+> - If the newly installed kernel fails to boot, you will
+ have to boot a good kernel, and then investigate why
+ the new kernel failed to boot.
+
+> - These steps are not specific to stable kernels.
+
+> - You can check out `linux mainline` or `linux-next` and
+ follow the same recipe of generating a new configuration
+ from an `oldconfig`, build, and install the `mainline`
+ or `linux-next` kernels.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/07-building-and-installing-kernel/06-quiz.md b/linux-kernel/course-Linux-Foundation-LFD103/07-building-and-installing-kernel/06-quiz.md
new file mode 100644
index 0000000..48ac005
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/07-building-and-installing-kernel/06-quiz.md
@@ -0,0 +1,17 @@
+## $\textnoraml{Knowledge Check}$
+
+```plaintext
+What is the ideal number of critical messages you should see in dmesg?
+ 0
+
+What steps are needed to configure grub to stop in the boot menu?
+ Comment out GRUB_TIMEOUT_STYLE=hidden
+ Uncomment GRUB_TIMEOUT and set it to 10: GRUB_TIMEOUT=10
+ Run update-grub
+
+How long will grub wait in the boot menu?
+ Time in seconds set in GRUB_TIMEOUT
+
+Which command shows emergency level kernel messages?
+ dmesg -l emerg
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/01-user-configuration-file.md b/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/01-user-configuration-file.md
new file mode 100644
index 0000000..058b566
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/01-user-configuration-file.md
@@ -0,0 +1,44 @@
+## $\textnormal{Creating a User-Specific Git Configuration File}$
+
+> - Let's start by configuring global git options, and
+ then you can go on to cloning the kernel repository.
+
+> - Create a user-specific Git configuration file named
+ `.gitconfig` in your home directory with your name,
+ email and other needed configurations.
+
+> - This information is used for commits and patch generation.
+
+> - The email in the `.gitconfig` file should be the same
+ email you will use to send patches.
+
+> - The `name` is the `Author` name, and the `email` is the
+ email address for the commit.
+
+> - Linux kernel developers will not accept a patch where
+ the `From` email differs from the `Signed-off-by` line,
+ which is what will happen if these two emails do not match.
+
+> - Configuring `signoff = true` as shown above adds the
+ `Signed-off-line` with the configured email as shown
+ above in `email=your.email@example.com` to the commit.
+
+> - This can be done manually by running the `git` command
+ with the `-s` option. E.g.:
+
+```sh
+git commit -s
+```
+
+> - Configure the `name= field` with your full legal name.
+
+> - I mentioned this earlier that by adding your Signed-off-by
+ line to a patch, you are certifying that you have read
+ and understood the `Developer's Certificate of Origin` and
+ abide by the `Linux Kernel Enforcement Statement`. Please
+ review the documents before you send patches to the kernel.
+
+```plaintext
+Developer's Certificate of Origin: https://www.kernel.org/doc/html/latest/process/submitting-patches.html
+Linux Kernel Enforcement Statement: https://www.kernel.org/doc/html/latest/process/kernel-enforcement-statement.html
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/02-kernel-configuration.md b/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/02-kernel-configuration.md
new file mode 100644
index 0000000..d6522e5
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/02-kernel-configuration.md
@@ -0,0 +1,58 @@
+## $\textnormal{Kernel Configuration}$
+
+> - Let's work with the mainline kernel to create your first patch.
+
+> - By this time, if you completed the exercises from the
+ previous chapters, you should already have the mainline
+ kernel running on your system.
+
+> - While doing that, I asked you to copy the distribution
+ configuration file to generate the kernel configuration.
+
+> - Now, let's talk about the kernel configuration.
+
+> - The Linux kernel is completely configurable.
+
+> - Drivers can be configured to be installed and completely
+ disabled. Here are three options for driver installation:
+
+```plaintext
+- Disabled
+- Built into the kernel ("vmlinux" image) to be loaded at boot time.
+- Built as a module to be loaded as needed using "modprobe".
+```
+
+> - It is a good idea to configure drivers as modules, to
+ avoid large kernel images.
+
+> - Modules (`.ko` files) can be loaded when the kernel
+ detects hardware that matches the driver.
+
+> - Building drivers as modules allows them to be loaded on
+ demand, instead of keeping them around in the kernel image
+ even when the hardware is either not being used, or not
+ even present on the system.
+
+> - We talked about generating the new configuration with the
+ old configuration as the starting point.
+
+> - New releases often introduce new configuration variables
+ and, in some cases, rename the configuration symbols.
+
+> - The latter causes problems, and `make oldconfig` might not
+ generate a new working kernel.
+
+> - Run `make listnewconfig` after copying the configuration
+ from `/boot` to the `.config` file, to see a list of new
+ configuration symbols.
+
+> - `Kconfig make config` is a good source about `Kconfig` and
+ `make config`.
+
+> - Please refer to the `Kernel Build System` to understand
+ the kernel build framework and the kernel makefiles.
+
+```plaintext
+Kconfig make config: https://www.kernel.org/doc/html/latest/kbuild/kconfig.html
+Kernel Build System: https://www.kernel.org/doc/html/latest/kbuild/index.html
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/03-creating-a-new-branch.md b/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/03-creating-a-new-branch.md
new file mode 100644
index 0000000..258eee4
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/03-creating-a-new-branch.md
@@ -0,0 +1,17 @@
+## $\textnormal{Creating a New Branch}$
+
+> - Before making a change, let's create a new branch in
+ the `linux_mainline` repository you cloned earlier
+ to write your first patch.
+
+> - We will start by adding a remote first to do a `rebase`
+ (pick up new changes made to the mainline).
+
+```sh
+cd linux_mainline
+git branch -a
+* master
+ remotes/linux/master
+ remotes/origin?HEAD -> origin/master
+ remotes/origin/master
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/04-adding-a-remote.md b/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/04-adding-a-remote.md
new file mode 100644
index 0000000..8b53062
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/04-adding-a-remote.md
@@ -0,0 +1,25 @@
+## $\textnormal{Adding a Remote}$
+
+> - Let’s add `git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git`
+ as the remote named `linux`.
+
+> - Adding a remote helps us fetch changes and choose a tag to rebase from.
+
+```sh
+git remote add linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
+git fetch linux
+remote: Counting objects: 3976, done.
+remote: Compressing objects: 100% (1988/1988), done.
+remote: Total 3976 (delta 2458), reused 2608 (delta 1969)
+Receiving objects: 100% (3976/3976), 6.67 MiB | 7.80 MiB/s, done.
+Resolving deltas: 100% (2458/2458), done.
+From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
+ 2a11c76e5301..ecb095bff5d4 master -> linux/master
+ * [new tag] v5.x-rc3 -> v5.x-rc3
+```
+
+> - We can pick a tag to rebase to.
+
+> - In this case, there is only one new tag.
+
+> - Let’s hold off on the rebase and start writing a new patch.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/05-checkout-the-branch.md b/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/05-checkout-the-branch.md
new file mode 100644
index 0000000..7b6da9f
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/05-checkout-the-branch.md
@@ -0,0 +1,12 @@
+## $\textnormal{Checkout the Branch}$
+
+> - To check out a branch do:
+
+```sh
+git checkout -b work
+master
+* work
+ remotes/linux/master
+ remotes/origin/HEAD -> origin/master
+ remotes/origin/master
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/06-making-changes-to-a-driver.md b/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/06-making-changes-to-a-driver.md
new file mode 100644
index 0000000..21d1b61
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/06-making-changes-to-a-driver.md
@@ -0,0 +1,122 @@
+## $\textnormal{Making Changes to a Driver}$
+
+> - Now, let’s select a driver to make a change.
+
+> - Run `lsmod` to see the modules loaded on your
+ system, and pick a driver to change.
+
+> - I will walk you through changing the `uvcvideo` driver.
+
+> - If you don’t have `uvcvideo` on your system, find
+ a different driver and follow along using
+ `your driver name` instead of `uvcvideo` files.
+
+```sh
+git grep uvcvideo -- '*Makefile'
+
+# Output.
+drivers/media/usb/uvc/Makefile:uvcvideo-objs := uvc_driver.o uvc_queue.o uvc_v4l2.o uvc_video.o uvc_ctrl.o drivers/media/usb/uvc/Makefile:uvcvideo-objs += uvc_entity.o
+drivers/media/usb/uvc/Makefile:obj-$(CONFIG_USB_VIDEO_CLASS) += uvcvideo.o
+```
+
+> - `uvcvideo` is a USB Video Class (UVC) media driver
+ for video input devices, such as webcams.
+
+> - It supports webcams on laptops. Let’s check the
+ source files for this driver.
+
+```sh
+ls drivers/media/usb/uvc/
+
+# Output.
+Kconfig uvc_debugfs.c uvc_isight.c uvc_status.c uvcvideo.h
+Makefile uvc_driver.c uvc_metadata.c uvc_v4l2.c
+uvc_ctrl.c uvc_entity.c uvc_queue.c uvc_video.c
+```
+
+> - Let's make a small change to the probe function of
+ the `uvcvideo` driver.
+
+> - A probe function is called when the driver is loaded.
+
+> - Let's edit `uvc_driver.c`:
+
+```sh
+vim drivers/media/usb/uvc/uvc_driver.c
+```
+
+> - Find the probe function by searching for `_probe`
+ text by typing / in standard mode.
+
+> - Once you've found the probe function, add `pr_info()`
+ to it and save the file.
+
+> - A `pr_info()` function writes a message to the kernel
+ log buffer, and we can see it using `dmesg`.
+
+```c
+static int uvc_probe(
+ struct usb_interface *intf,
+ const struct usb_device_id *id
+) {
+ struct usb_device *udev = interface_to_usbdev(intf);
+ struct uvc_device *dev;
+ const struct uvc_device_info *info = (const struct uvc_device_info *)id->driver_info;
+ int function;
+ int ret;
+
+ pr_info("I changed uvcvideo driver in the Linux Kernel\n");
+
+ if (id->idVendor && id->idProduct) {
+ uvc_trace(
+ UVC_TRACE_PROBE,
+ "Probing known UVC device %s " "(%04x:%04x)\n",
+ udev->devpath,
+ id->idVendor,
+ id->idProduct
+ );
+ } else {
+ uvc_trace(
+ UVC_TRACE_PROBE,
+ "Probing generic UVC device %s\n",
+ udev->devpath
+ );
+ }
+```
+
+> - Let’s try configuring `uvcvideo` as a built-in and as a
+ module to play with installing, loading and unloading modules.
+
+> - Configure as a module:
+
+```plaintext
+- Configure "CONFIG_USB_VIDEO_CLASS=y"
+- Recompile your kernel and install. Please note that you don't
+ have to reboot your system. You can load your newly installed
+ module.
+```
+
+> - Load module:
+
+```plaintext
+- "sudo modprobe uvcvideo"
+- Once you load the module, let's check if you see your message.
+- Run "dmesg | less" and search for "I changed". Do you see the message?
+- Run "lsmod | grep uvcvideo". Do you see the module?
+```
+
+> - Unload module:
+
+```plaintext
+- "sudo rmmod uvcvideo"
+- Check "dmesg" for any messages about the "uvcvideo" module removal.
+- Run "lsmod | grep uvcvideo". Do you see the module?
+```
+
+> - Configure Built-in:
+
+```plaintext
+- Configure "CONFIG_USB_VIDEO_CLASS=y"
+- Recompile your kernel, install, and reboot the system into the newly installed kernel.
+- Run "dmesg | less" and search for "I changed". Do you see the message?
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/07-practicing-commits.md b/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/07-practicing-commits.md
new file mode 100644
index 0000000..fdd2910
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/07-practicing-commits.md
@@ -0,0 +1,83 @@
+## $\textnormal{Practicing Commits}$
+
+> - You can see the files you modified by running
+ the `git status` command.
+
+> - Let's first check if your changes follow the
+ coding guidelines outlined in the Linux kernel
+ coding style guide.
+
+```plaintext
+Linux Kernel Coding Style Guide: https://www.kernel.org/doc/html/latest/process/coding-style.html
+```
+
+> - You can run `checkpatch.pl` on the diff or the
+ generated patch to verify if your changes comply
+ with the coding style.
+
+```plaintext
+checkpath.pl: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/checkpatch.pl
+```
+
+> - It is good practice to check by running `checkpatch.pl`
+ on the diff before testing and committing the changes.
+
+> - I find it useful to do this step even before I
+ start testing my patch.
+
+> - This helps avoid redoing testing in case code changes
+ are necessary to address the `checkpatch` errors and
+ warnings.
+
+> - You can see my patch workflow below.
+
+| Patch Workflow |
+| -------------- |
+|  |
+
+
+
+> - Make sure you address `checkpatch` errors and/or warnings.
+
+> - Once `checkpatch` is happy, test your changes and commit
+ your changes.
+
+> - If you want to commit all modified files, run:
+
+```sh
+git commit -a
+```
+
+> - If you have changes that belong in separate patches, run:
+
+```sh
+git commit
+```
+
+> - When you commit a patch, you will have to describe what
+ the patch does.
+
+> - The commit message has a subject or short log and longer
+ commit message.
+
+> - It is important to learn what should be in the commit log
+ and what doesn’t make sense.
+
+> - Including what code does isn’t very helpful, whereas why
+ the code change is needed is valuable.
+
+> - Please read How to Write a Git Commit Message for tips on
+ writing good commit messages.
+
+```plaintext
+How to Write a Git Commit Message: https://cbea.ms/git-commit/
+```
+
+> - Now, run the commit and add a commit message.
+
+> - After committing the change, generate the patch running the
+ following command:
+
+```sh
+git format-patch -1
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/09-quiz.md b/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/09-quiz.md
new file mode 100644
index 0000000..1a8d96e
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/09-quiz.md
@@ -0,0 +1,29 @@
+## $\textnormal{Knowledge Check}$
+
+```plaintext
+When CONFIG_USB_AUDIO=m is in your configuration, the USB Audio
+driver is built into the kernel.
+ False
+
+Configuring drivers as modules helps to:
+ Avoid loading modules that might not be needed.
+ Keep kernel size small.
+
+Which commands are used to manage modules?
+ modprobe
+ lsmod
+ rmmod
+
+Describing the code change details in the commit log is useful?
+ False
+
+What does "checkpath.pl" do?
+ Checks a patch for coding style compliance.
+ Checks a patch for spelling errors.
+ Prompts for adding new files to MAINTAINERS files.
+ Checks for mismatched "from" and "author" email addresses.
+
+Make a small change to a file of your choice and run git status.
+What does git status show?
+ Changed file and other non-git artifacts, if any.
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/images/01-patch-workflow.png b/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/images/01-patch-workflow.png
new file mode 100644
index 0000000..0a2919a
Binary files /dev/null and b/linux-kernel/course-Linux-Foundation-LFD103/08-writing-your-own-kernel-patch/images/01-patch-workflow.png differ
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/01-sending-a-patch-for-review.md b/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/01-sending-a-patch-for-review.md
new file mode 100644
index 0000000..a3bff35
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/01-sending-a-patch-for-review.md
@@ -0,0 +1,58 @@
+## $\textnormal{Sending a Patch for Review}$
+
+> - So far, you learned how to make a change, check for
+ coding style compliance, and generate a patch.
+
+> - The next step is learning the logistics of how to
+ send a patch to the Linux Kernel mailing lists
+ for review.
+
+> - The `get_maintainer.pl` script tells you whom to
+ send the patch to.
+
+> - The two example runs of `get_maintainer.pl` show the
+ list of people to send patches to.
+
+> - You should send the patch to maintainers, commit
+ signers, supporters, and all the mailing lists shown
+ in the `get_maintainer.pl` output.
+
+> - Mailing lists are on the `“cc”` and the rest are on
+ the `“To”` list when a patch is sent.
+
+| Mailing List 1 |
+| -------------- |
+|  |
+
+
+
+> - Now let’s run the `get_maintainer.pl` script on your changes.
+
+| Mailing List 2 |
+| -------------- |
+|  |
+
+
+
+> - As this time, you can run:
+
+```sh
+git format-patch -1 --to=laurent.pinchart@ideasonboard.com --to=mchehab@kernel.org --cc=linux-media@vger.kernel.org --cc=linux-kernel@vger.kernel.org
+```
+
+> - This will generate a patch. You can send this patch using:
+
+```sh
+git send-email
+```
+
+> - You won’t be sending this patch and you can revert this commit.
+
+> - Please refer to the Select the recipients for your patch
+ section in the Submitting patches: the essential guide to
+ getting your code into the kernel document.
+
+```plaintext
+Select the Recipients for your Patch: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#select-the-recipients-for-your-patch
+Submitting Patches: Essential Guide: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#submitting-patches-the-essential-guide-to-getting-your-code-into-the-kernel
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/02-review-process.md b/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/02-review-process.md
new file mode 100644
index 0000000..42ad7cb
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/02-review-process.md
@@ -0,0 +1,40 @@
+## $\textnormal{The Review Process}$
+
+> - Your patch will get comments from reviewers with
+ suggestions for improvements and, in some cases,
+ learning to know more about the change itself.
+
+> - Please be patient and wait for a minimum of one
+ week before requesting a response.
+
+> - During merge windows and other busy times, it
+ might take longer than a week to get a response.
+
+> - Also, make sure you sent the patch to the right
+ recipients.
+
+> - Please thank the reviewers for their comments and
+ address them.
+
+> - Don’t hesitate to ask a clarifying question if you
+ don’t understand the comment.
+
+> - When you send a new version of your patch, add
+ version history describing the changes made in the
+ new version.
+
+> - The right place for the version history is after
+ the "---" below the Signed-off-by tag and the start
+ of the changed file list, as shown in the screenshot below.
+
+> - Everything between the Signed-off-by and the diff
+ is just for the reviewers, and will not be included
+ in the commit.
+
+> - Please don’t include version history in the commit log.
+
+| Patch Version History |
+| --------------------- |
+|  |
+
+
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/03-best-practices-for-sending-patches.md b/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/03-best-practices-for-sending-patches.md
new file mode 100644
index 0000000..32f58af
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/03-best-practices-for-sending-patches.md
@@ -0,0 +1,111 @@
+## $\textnormal{Best Practices for Sending Patches}$
+
+> - A few tips and best practices for sending patches:
+
+```plaintext
+- Run "scripts/checkpatch.pl" before sending the patch. Note
+ that "checkpatch.pl" might suggest changes that are unnecessary!
+ Use your best judgement when deciding whether it makes sense
+ to make the change "checkpatch.pl" suggests. The end goal is for
+ the code to be more readable. If "checkpatch.pl" suggests a
+ change and you think the end result is not more readable,
+ don't make the change. For example, if a line is 81 characters
+ long, but breaking it makes the resulting code look ugly,
+ don't break that line.
+
+- Compile and test your change.
+
+- Document your change and include relevant testing details and
+ results of that testing.
+
+- "Signed-off-by" should be the last tag.
+
+- As a general rule, don't include change lines in the commit log.
+
+- Remember that good patches get accepted quicker. It is important
+ to understand how to create good patches.
+
+- Copy mailing lists and maintainers/developers suggested by
+ "scripts/get_maintainer.pl".
+
+- Be patient and wait for a minimum of one week before requesting
+ for comments. It could take longer than a week during busy periods
+ such as the merge windows.
+
+- Always thank the reviewers for their feedback and address them.
+
+- Don’t hesitate to ask a clarifying question if you don’t understand the comment.
+
+- When working on a patch based on a suggested idea, make sure to
+ give credit using the "Suggested-by: tag. Other tags used for
+ giving credit are "Tested-by", "Reported-by".
+
+ Other Tags: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes
+
+- Remember that the reviewers help improve code. Don’t take it
+ personally and handle the feedback gracefully. Please don’t
+ do top post when responding to emails. Responses should be
+ inlined.
+
+- Keep in mind that the community doesn’t have any obligation to
+ accept your patch. Patches are pulled, not pushed. Always give
+ a reason for the maintainer to take your patch.
+
+- Be patient and be ready to make changes and working with the
+ reviewers. It could take multiple versions before your patch
+ gets accepted. It is okay to disagree with maintainers and
+ reviewers. Please don't ignore a review because you disagree
+ with it. Present your reasons for disagreeing, along with
+ supporting technical data such as benchmarks and other
+ improvements.
+
+- In general, getting response and comments is a good sign
+ that the community likes the patch and wants to see it improved.
+ Silence is what you want to be concerned about. If you
+ don't hear any response back from the maintainer after
+ a week, feel free to either send the patch again, or send
+ a gentle "ping" - something like "Hi, I know you are busy,
+ but have you found time to look at my patch?"
+
+- Expect to receive comments and feedback at any time during
+ the review process.
+
+- Stay engaged and be ready to fix problems, if any, after
+ the patch gets accepted into linux-next for integration
+ into the mainline. Kernel build and Continuous Integration
+ (CI) bots and rings u`sually find problems.
+
+- When a patch gets accepted, you will either see an email
+ from the maintainer or an automated patch accepted email
+ with information on which tree it has been applied to,
+ and some estimate on when you can expect to see it in the
+ mainline kernel. Not all maintainers might send an email
+ when the patch gets merged. The patch could stay in linux-next
+ for integration until the next merge window, before it gets
+ into Linus's tree. Unless the patch is an actual fix to
+ a bug in Linus's tree, in which case, it may go directly into his tree.
+
+- Sometimes you need to send multiple related patches. This
+ is useful for grouping, say, to group driver clean up patches
+ for one particular driver into a set, or grouping patches
+ that are part of a new feature into one set. git format-patch
+ -2 -s --cover-letter --thread --subject-prefix="PATCH v3"
+ --to= “name” --cc=” name” will create a threaded patch series
+ that includes the top two commits and generated cover letter
+ template. It is a good practice to send a cover letter when
+ sending a patch series.
+
+- Including patch series version history in the cover letter
+ will help reviewers get a quick snapshot of changes from
+ version to version.
+
+ https://lkml.org/lkml/2019/9/17/657
+
+- When a maintainer accepts a patch, the maintainer assumes
+ maintenance responsibility for that patch. As a result,
+ maintainers have decision power on how to manage patch
+ flow into their individual sub-system(s) and they also
+ have individual preferences. Be prepared for
+ maintainer-to-maintainer differences in commit log
+ content and sub-system specific coding styles.
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/04-git-post-commit-hooks.md b/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/04-git-post-commit-hooks.md
new file mode 100644
index 0000000..159a196
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/04-git-post-commit-hooks.md
@@ -0,0 +1,37 @@
+## $\textnormal{Git Post-Commit Hooks}$
+
+> - Git includes some `hooks` for scripts that can be
+ run before or after specific git commands are
+ executed.
+
+> - Checking the patch for compliance and errors
+ can be automated using git pre-commit and
+ post-commit hooks.
+
+> - The `post-commit` hook is run after you make
+ a git commit with the git commit command.
+
+> - If you don't already have `/usr/share/codespell/dictionary.txt`, do:
+
+```sh
+sudo apt-get install codespell
+```
+
+> - If you already have a `.git/hooks/post-commit` file, move it
+ to `.git/hooks/post-commit.sample`. git will not execute files
+ with the `.sample` extension. Then, edit the `.git/hooks/post-commit`
+ file to contain only the following two lines:
+
+```sh
+#!bash
+#!/bin/sh
+exec git show --format=email HEAD | ./scripts/checkpatch.pl --strict --codespell
+# Make sure the file is executable:
+chmod a+x .git/hooks/post-commit
+```
+
+> - After you make the commit, this hook will output any `checkpatch`
+ errors or warnings that your patch creates. If you see warnings
+ or errors that you know you added, you can amend the commit by
+ changing the file, using `git add` to add the changes, and then
+ using `git commit --amend` to commit the changes.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/05-quiz.md b/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/05-quiz.md
new file mode 100644
index 0000000..39d1159
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/05-quiz.md
@@ -0,0 +1,22 @@
+## $\textnormal{Knowledge Check}$
+
+```plaintext
+What does the "checkpatch.pl" script not tell you?
+ Checks if a patch will apply correctly.
+
+What does the "get_maintainers.pl" script tell you?
+ All recipients for the patch, including maintainers,
+ commit signers, and mailing lists.
+
+Who is responsible for accepting or rejecting patches?
+ Maintainers for the sub-system.
+
+How long is the minimum wait time before asking for comments on the patch?
+ One week
+
+Which tag should be the last tag in the patch?
+ Signed-off by
+
+Which is one thing that will most definitely get your patch rejected?
+ Sending patches with mismatched Signed-off-by and From email addresses
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/images/01-mailing-lists.png b/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/images/01-mailing-lists.png
new file mode 100644
index 0000000..7fc58ff
Binary files /dev/null and b/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/images/01-mailing-lists.png differ
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/images/02-mailing-lists-2.png b/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/images/02-mailing-lists-2.png
new file mode 100644
index 0000000..17dc27b
Binary files /dev/null and b/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/images/02-mailing-lists-2.png differ
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/images/03-patch-version-history.png b/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/images/03-patch-version-history.png
new file mode 100644
index 0000000..a2466ad
Binary files /dev/null and b/linux-kernel/course-Linux-Foundation-LFD103/09-getting-your-patch-ready-and-sending-it/images/03-patch-version-history.png differ
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/10-kernel-and-driver-building-loading-and-dependencies/01-compiling-at-directory-level.md b/linux-kernel/course-Linux-Foundation-LFD103/10-kernel-and-driver-building-loading-and-dependencies/01-compiling-at-directory-level.md
new file mode 100644
index 0000000..af497b0
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/10-kernel-and-driver-building-loading-and-dependencies/01-compiling-at-directory-level.md
@@ -0,0 +1,44 @@
+## $\textnormal{Compiling a Single Source File: make path/file.o}$
+
+> - Let's see how we can build a driver or module or
+ a single source file in the kernel.
+
+> - Compiling a single source file: `make path/file.o`:
+
+```sh
+make drivers/media/test-drivers/vimc/vimc-core.o
+
+# Output.
+CALL scripts/checksyscalls.s
+CALL scripts/atomic/check-atomics.sh
+DESCEND objtool
+CC [M] drivers/media/test-drivers/vimc/vimc-core.o
+```
+
+> - Compiling at the directory level: `make path`:
+
+```sh
+make drivers/media/test-drivers/vimc/
+
+# Output.
+CALL scripts/checksyscalls.sh
+CALL scripts/atomic/check-atomics.sh
+DESCEND objtool
+CC [M] drivers/media/test-drivers/vimc/vimc-core.o
+CC [M] drivers/media/test-drivers/vimc/vimc-common.o
+CC [M] drivers/media/test-drivers/vimc/vimc-streamer.o
+CC [M] drivers/media/test-drivers/vimc/vimc-capture.o
+CC [M] drivers/media/test-drivers/vimc/vimc-debayer.o
+CC [M] drivers/media/test-drivers/vimc/vimc-scaler.o
+CC [M] drivers/media/test-drivers/vimc/vimc-sensor.o
+LD [M] drivers/media/test-drivers/vimc/vimc.o
+```
+
+> - The two examples we provided show us how to
+ compile a single source file for the driver
+ vimc, which resides at `drivers/media/test-drivers/vimc`.
+
+> - You can see how the first `make` command just
+ compiles the source file and the second one builds the driver.
+
+> - Running `make ` localizes a build to the specified `path`.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/10-kernel-and-driver-building-loading-and-dependencies/02-compiling-a-module.md b/linux-kernel/course-Linux-Foundation-LFD103/10-kernel-and-driver-building-loading-and-dependencies/02-compiling-a-module.md
new file mode 100644
index 0000000..cea7c78
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/10-kernel-and-driver-building-loading-and-dependencies/02-compiling-a-module.md
@@ -0,0 +1,128 @@
+## $\textnormal{Compiling a Module}$
+
+> - Next, let's look at the following variation
+ that builds the `vimc` module:
+
+```sh
+make M=drivers/media/test-drivers/vimc
+
+# Output.
+CC [M] drivers/media/test-drivers/vimc/vimc-core.o
+CC [M] drivers/media/test-drivers/vimc/vimc-common.o
+CC [M] drivers/media/test-drivers/vimc/vimc-streamer.o
+CC [M] drivers/media/test-drivers/vimc/vimc-capture.o
+CC [M] drivers/media/test-drivers/vimc/vimc-debayer.o
+CC [M] drivers/media/test-drivers/vimc/vimc-scaler.o
+CC [M] drivers/media/test-drivers/vimc/vimc-sensor.o
+LD [M] drivers/media/test-drivers/vimc/vimc.o
+Building modules, stage 2.
+MODPOST 1 modules
+CC drivers/media/test-drivers/vimc/vimc.mod.o
+LD [M] drivers/media/test-drivers/vimc/vimc.ko
+```
+
+
+
+> - Sometimes, it is hard to figure out all the
+ dependencies for a module, or a driver, or a
+ configuration option.
+
+> - Until all the dependencies are enabled, the
+ driver you are looking to enable will not be
+ enabled.
+
+> - Let’s take a look at `drivers/media/test-drivers/vimc/Kconfig`.
+
+```sh
+config VIDEO_VIMC
+ tristate "Virtual Media Controller Driver (VIMC)"
+ depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ select VIDEOBUF2_VMALLOC
+ select VIDEO_V4L2_TPG
+ help
+ Skeleton driver for Virtual Media Controller
+
+ This driver can be compared to the vivid driver for emulating
+ a media node that exposes a complex media topology. The topology
+ is hard coded for now but is meant to be highly configurable in
+ the future.
+
+ When in doubt, say N.
+```
+
+
+
+> - We can see that vimc can be enabled by changing
+ the `CONFIG_VIDEO_VIMC` option.
+
+> - It is a tristate driver.
+
+> - What that means is that it can be:
+
+```plaintext
+- enabled as a built-in
+- enabled as a module
+- disabled.
+```
+
+
+
+> - It depends on `CONFIG_VIDEO_DEV`, `CONFIG_VIDEO_V4L2`, and
+ `CONFIG_VIDEO_V4L2_SUBDEV_API` to be enabled. It will also
+ autoselect `CONFIG_VIDEOBUF2_VMALLOC` and `CONFIG_VIDEO_V4L2_TPG`.
+
+```plaintext
+- Enable as a module: CONFIG_VIDEO_VIMC=m
+- Enable as built-in: CONFIG_VIDEO_VIMC=y
+- Disable: CONFIG_VIDEO_VIMC=n or #CONFIG_VIDEO_VIMC
+```
+
+
+
+> - Some options are boolean. That means these modules or options
+ can be enabled or disabled. It might take a couple of attempts
+ to enable all the dependencies. We recommend using `make menuconfig`
+ to enable drivers and other configuration options.
+
+| Kernel Configuration: make menuconfig |
+| -------------------- |
+|  |
+
+
+
+> - Vimc resides under the `Device Drivers` option.
+
+> - Using the down arrow, you can navigate to the `Device Drivers`
+ option and take a look at what there is in there.
+
+> - You can use the "/" option to search.
+
+> - We are showing the long road to give you more details on the
+ configuration hierarchy.
+
+| menuconfig Device Drivers |
+| ------------------------- |
+|  |
+
+
+
+> - Now navigate down until you see `Multimedia support` and then
+ follow the `Media test drivers` option.
+
+> - You will see `vimc` there.
+
+| menuconfig vimc |
+| --------------- |
+|  |
+
+
+
+> - In our configuration, we have it enabled as a module.
+
+> - If you would like to change it, scroll down and this will
+ highlight the `M`, at which point you can change it by
+ just pressing `Enter`, which will toggle through all three
+ options for this driver.
+
+> - That’s enough fun with `menuconfig` for now. We will leave
+ it to you to play with other options.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/10-kernel-and-driver-building-loading-and-dependencies/03-quiz.md b/linux-kernel/course-Linux-Foundation-LFD103/10-kernel-and-driver-building-loading-and-dependencies/03-quiz.md
new file mode 100644
index 0000000..d510796
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/10-kernel-and-driver-building-loading-and-dependencies/03-quiz.md
@@ -0,0 +1,21 @@
+## $\textnormal{Knowledge Check}$
+
+```plaintext
+Which of the following options would you use to compile a single source file?
+ make path/file.o
+
+Which of the following options would you use to build a module?
+ make M=path
+
+Using "make menuconfig" makes it easier to navigate the configuration options
+and resolve dependencies. True or False?
+ True
+
+A tristate module cannot be configured as a built-in or a module or disabled.
+True or False?
+ False
+
+A driver or a module can only be enabled when all the dependencies are met.
+True or False
+ True
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/10-kernel-and-driver-building-loading-and-dependencies/images/01-kernel-configuration.png b/linux-kernel/course-Linux-Foundation-LFD103/10-kernel-and-driver-building-loading-and-dependencies/images/01-kernel-configuration.png
new file mode 100644
index 0000000..b2d999c
Binary files /dev/null and b/linux-kernel/course-Linux-Foundation-LFD103/10-kernel-and-driver-building-loading-and-dependencies/images/01-kernel-configuration.png differ
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/10-kernel-and-driver-building-loading-and-dependencies/images/02-menuconfig-device-drivers.png b/linux-kernel/course-Linux-Foundation-LFD103/10-kernel-and-driver-building-loading-and-dependencies/images/02-menuconfig-device-drivers.png
new file mode 100644
index 0000000..40d93a8
Binary files /dev/null and b/linux-kernel/course-Linux-Foundation-LFD103/10-kernel-and-driver-building-loading-and-dependencies/images/02-menuconfig-device-drivers.png differ
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/10-kernel-and-driver-building-loading-and-dependencies/images/03-menuconfig-vimc.png b/linux-kernel/course-Linux-Foundation-LFD103/10-kernel-and-driver-building-loading-and-dependencies/images/03-menuconfig-vimc.png
new file mode 100644
index 0000000..0f7aa78
Binary files /dev/null and b/linux-kernel/course-Linux-Foundation-LFD103/10-kernel-and-driver-building-loading-and-dependencies/images/03-menuconfig-vimc.png differ
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/01-testing-open-source-software.md b/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/01-testing-open-source-software.md
new file mode 100644
index 0000000..a46a73e
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/01-testing-open-source-software.md
@@ -0,0 +1,47 @@
+## $\textnormal{Testing Open Source Software}$
+
+> - Ensuring software is stable without regressions before the
+ release helps avoid debugging and fixing customer- and
+ user-found bugs after the release.
+
+> - It costs more in time and effort to debug and fix a
+ customer-found problem.
+
+> - Hence, testing is very important when it comes to any
+ software, not just the Linux kernel.
+
+> - Unlike closed and proprietary operating systems, the
+ development process is open. and is not locked down.
+
+> - This process is its strength, as well as its weakness.
+
+> - With several developers continuing to add new features,
+ and fixing bugs, continuous integration and testing is
+ vital to ensure the kernel continues to work on existing
+ hardware as new hardware support and features get added.
+
+> - In the open source development model, developers and users
+ share the testing responsibility.
+
+> - This is another important difference between a closed
+ development model and an open one.
+
+> - The majority of Linux kernel developers, if not all, are
+ very active Linux users themselves.
+
+> - There is no requirement that testers should be developers.
+
+> - However, users and developers that are not familiar with
+ the new code may be more effective at testing a new piece
+ of code than the original author of that code.
+
+> - In other words, while developer testing serves as an
+ important step in verifying the functionality of the software,
+ developer testing alone is not sufficient to find
+ interactions with other code, features, and unintended
+ regressions on configurations and/or hardware, the developer
+ did not anticipate and did not have the opportunity and
+ resources to test.
+
+> - Hence, users play a very important role in the Linux Kernel
+ development process.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/02-automated-build-bots.md b/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/02-automated-build-bots.md
new file mode 100644
index 0000000..0f83fce
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/02-automated-build-bots.md
@@ -0,0 +1,33 @@
+## $\textnormal{Automated Build Bots and Continuous Integration Test Rings}$
+
+> - Automated build bots and Continuous Integration (CI) test
+ rings run tests on various kernel repositories.
+
+> - Maintainers and developers can request their repositories
+ to be added to the `linux-next` integration tree and the
+ 0-day build bot.
+
+> - The 0-day build bot can pull in patches and run build tests
+ on several configurations and architectures.
+
+> - It is helpful in finding compile errors and warnings that
+ might show up on other architectures that developers might
+ not have access to.
+
+> - Continuous Integration (CI) rings are test farms that host
+ several platforms and run boot tests and Kernel Selftests
+ on `stable`, `linux-next`, and `mainline` trees.
+
+> - All these tests are run on real hardware, as well as Qemu
+ environments, covering a wide range of architectures and
+ configurations.
+
+> - Please take a look at the following resources for the latest
+ status on kernel releases:
+
+```plaintext
+Kernel CI Dashboard: https://kernelci.org/
+0-Day - Boot and Performance Issues: https://lists.01.org/hyperkitty/
+Linaro QA: https://qa-reports.linaro.org/lkft/
+Buildbot: https://kerneltests.org/
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/03-applying-patches.md b/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/03-applying-patches.md
new file mode 100644
index 0000000..893d5d6
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/03-applying-patches.md
@@ -0,0 +1,61 @@
+## $\textnormal{Applying Patches}$
+
+> - As we already talked about, the Linux kernel patch
+ files are text files that contain the differences
+ from the original source to the new source.
+
+> - Each Linux patch is a self-contained change to the
+ code that stands on its own, unless explicitly made
+ part of a patch series.
+
+> - New patches are applied as follows:
+
+```sh
+patch -p1 < file.patch
+git apply --index file.patch
+```
+
+> - Either command will work; however, when a patch adds
+ a new file and, if it is applied using the patch
+ command, git does not know about the new files, and
+ they will be treated as untracked files.
+
+> - The `git diff` command will not show the files in its
+ output and the `git status` command will show the files
+ as untracked.
+
+> - You can use `git diff HEAD` to see the changes.
+
+> - For the most part, there are no issues with building
+ and installing kernels; however, the `git reset --hard`
+ command will not remove the newly created files and a
+ subsequent `git pull` will fail.
+
+> - Available options:
+
+```plaintext
+Option 1
+ When a patch that adds new files is applied using the
+ patch command, run git clean to remove untracked files
+ before running git reset --hard.
+
+ For example, git clean -dfx will force the removal of
+ untracked directories and files, ignoring any standard
+ ignore rules specified in the .gitignore file.
+
+ You could include the -q option to run git clean in
+ quiet mode, if you do not care to know which files
+ are removed.
+
+Option 2
+ An alternate approach is to tell git to track the newly
+ added files by running git apply --index file.patch.
+
+ This will result in git applying the patch and adding
+ the result to the index.
+
+ Once this is done, git diff will show the newly added
+ files in its output and git status will report the
+ status correctly, tagging these files as newly created
+ files.
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/04-basic-testing.md b/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/04-basic-testing.md
new file mode 100644
index 0000000..cb5c22d
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/04-basic-testing.md
@@ -0,0 +1,21 @@
+## $\textnormal{Basic Testing}$
+
+> - Once a new kernel is installed, the next step is to
+ try to boot it and see what happens.
+
+> - Once the new kernel is up and running, check dmesg
+ for any regressions.
+
+> - Run a few usage tests:
+
+```plaintext
+- Is networking (wifi or wired) functional?
+- Does ssh work?
+- Run rsync of a large file over ssh
+- Run git clone and git pull
+- Start a web browser
+- Read email
+- Download files: ftp, wget, etc.
+- Play audio/video files
+- Connect new USB devices - mouse, USB stick, etc.
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/05-examining-kernel-logs.md b/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/05-examining-kernel-logs.md
new file mode 100644
index 0000000..b055048
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/05-examining-kernel-logs.md
@@ -0,0 +1,31 @@
+## $\textnormal{Examining Kernel Logs}$
+
+> - Checking for regressions in `dmesg` is a good way
+ to identify problems, if any, introduced by the new code.
+
+> - As a general rule, there should be no new `crit`,
+ `alert`, and `emerg` level messages in `dmesg`.
+
+> - There should be no new err level messages.
+
+> - Pay close attention to any new warn level messages
+ as well.
+
+> - Please note that new warn messages are not as bad.
+
+> - At times, new code adds new warning messages which
+ are just warnings.
+
+```sh
+dmesg -t -l emerg
+dmesg -t -l crit
+dmesg -t -l alert
+dmesg -t -l err
+dmesg -t -l warn
+dmesg -t -k
+dmesg -t
+```
+
+> - Are there any stack traces resulting from `WARN_ON`
+ in the `dmesg`? These are serious problems that require
+ further investigation.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/06-stress-testing.md b/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/06-stress-testing.md
new file mode 100644
index 0000000..6173b1c
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/06-stress-testing.md
@@ -0,0 +1,27 @@
+## $\textnormal{Stress Testing}$
+
+> - Running three to four kernel compiles in parallel is a
+ good overall stress test.
+
+> - Download a few Linux kernel gits, stable, linux-next etc.
+
+> - Run timed compiles in parallel.
+
+> - Compare times with old runs of this test for regressions
+ in performance.
+
+> - Longer compile times could be indicators of performance
+ regression in one of the kernel modules.
+
+> - Performance problems are hard to debug.
+
+> - The first step is to detect them.
+
+> - Running several compiles in parallel is a good overall
+ stress test that could be used as a performance regression
+ test and overall kernel regression test, as it exercises
+ various kernel modules like memory, filesystems, dma, and drivers.
+
+```sh
+time make all
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/07-debug-options.md b/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/07-debug-options.md
new file mode 100644
index 0000000..5935f83
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/07-debug-options.md
@@ -0,0 +1,36 @@
+## $\textnormal{Debug Options and Proactive Testing}$
+
+> - As you are making changes to drivers and other areas
+ in the kernel, there are a few things to watch out for.
+
+> - There are several configuration options to test for
+ locking imbalances and deadlocks.
+
+> - It is important to remember to enable the `Lock Debugging`
+ and `CONFIG_KASAN` for memory leak detection.
+
+> - We do not intend to cover debugging in depth in this
+ chapter, but we want you to start thinking about
+ debugging and configuration options that facilitate debugging.
+
+> - Enabling the following configuration option is recommended
+ for testing your changes to the kernel:
+
+```sh
+CONFIG_KASAN
+CONFIG_KMSAN
+CONFIG_UBSAN
+CONFIG_LOCKDEP
+CONFIG_PROVE_LOCKING
+CONFIG_LOCKUP_DETECTOR
+```
+
+> - I will leave you to play with these debug configuration
+ options and explore others.
+
+> - Running `git grep -r DEBUG | grep Kconfig` can find all
+ supported debug configuration options.
+
+```plaintext
+LF Live Mentorship Series: https://events.linuxfoundation.org/lf-live-mentorship-series/
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/08-quiz.md b/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/08-quiz.md
new file mode 100644
index 0000000..642123b
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/11-all-about-testing/08-quiz.md
@@ -0,0 +1,17 @@
+## $\textnormal{Knowledge Check}$
+
+```plaintext
+Which of the following rings and bots help validate patches
+and kernel releases.
+ 0-day build bot
+ Continuous Integration (testing) rings
+
+Which of the following applyt to validation on CI rings and
+build bots?
+ Boot tests
+ Qemu tests
+ Kernel Selftests
+ Compile tests
+ Real hardware
+ Cover a wide range of architectures and configurations
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/12-debugging-basics/01-overview.md b/linux-kernel/course-Linux-Foundation-LFD103/12-debugging-basics/01-overview.md
new file mode 100644
index 0000000..8ba1539
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/12-debugging-basics/01-overview.md
@@ -0,0 +1,24 @@
+## $\textnormal{Debugging Overview}$
+
+> - Debugging is an art, and not a science.
+
+> - There is no step-by-step procedure or a single
+ recipe for success when debugging a problem.
+
+> - Asking the following questions can help to understand
+ and identify the nature of the problem and how best to
+ solve it:
+
+```plaintext
+- Is the problem easily reproducible?
+- Is there a reproducer or test that can trigger the bug consistently?
+- Are there any panic, or error, or debug messages in the dmesg when the bug is triggered?
+- Is reproducing the problem time-sensitive?
+```
+
+> - Easily reproducible bugs with a test to trigger
+ make it easier to debug, identify the problem,
+ fix it and verify the fix.
+
+> - Time-sensitive problems could be a result of race
+ conditions, and these are harder to debug and fix.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/12-debugging-basics/02-panic-message.md b/linux-kernel/course-Linux-Foundation-LFD103/12-debugging-basics/02-panic-message.md
new file mode 100644
index 0000000..d1448cc
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/12-debugging-basics/02-panic-message.md
@@ -0,0 +1,14 @@
+## $\textnormal{What is Panic Message}$
+
+> - Let’s start with a primer on what each word in
+ the panic means and how to interpret them.
+
+> - The following two blogs are good resources to refer to:
+
+```plaintext
+Debugging Analysis of Kernel Panics and Kernel OOPSes Using System Map
+ https://sanjeev1sharma.wordpress.com/tag/debug-kernel-panics/
+
+Understanding a Kernel Oops!
+ https://www.opensourceforu.com/2011/01/understanding-a-kernel-oops/
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/12-debugging-basics/03-decode-and-analyze.md b/linux-kernel/course-Linux-Foundation-LFD103/12-debugging-basics/03-decode-and-analyze.md
new file mode 100644
index 0000000..de94ed8
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/12-debugging-basics/03-decode-and-analyze.md
@@ -0,0 +1,39 @@
+## $\textnormal{Decode and Analyze the Panic Message}$
+
+> - Panic messages can be decoded using the `decode_stacktrace.sh< tool. Please refer to xtagstartza href="https://lwn.net/Articles/592724/" target="_blank" style="color:#0099cc">decode_stacktrace: make stack dump output useful again` for details on how to use the tool.
+
+```plaintext
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/decode_stacktrace.sh
+```
+
+```sh
+Usage:
+ scripts/decode_stacktrace.sh -r | [base path] [modules path]
+
+Save (cut and paste) the panic trace in the dmesg between the two following lines of text into a .txt file.
+
+------------[ cut here ]------------
+---[ end trace …. ]---
+```
+
+> - Run this tool in your kernel repo.
+
+> - You will have to supply the `[base path]`, which is the root
+ of the git repo where the `vmlinux` resides if it is different
+ from the location the tool is run from.
+
+> - If the panic is in a dynamically kernel module, you will have
+ to pass in the `[modules path]` where the modules reside.
+
+```sh
+scripts/decode_stacktrace.sh ./vmlinux < panic_trace.txt
+```
+
+> - Reading code:
+
+```plaintext
+- It goes without saying that reading code and
+ understanding the call trace leading up to the
+ failure is an essential first step to debugging
+ and finding a suitable fix.
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/12-debugging-basics/04-use-event-tracing.md b/linux-kernel/course-Linux-Foundation-LFD103/12-debugging-basics/04-use-event-tracing.md
new file mode 100644
index 0000000..b8593db
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/12-debugging-basics/04-use-event-tracing.md
@@ -0,0 +1,95 @@
+## $\textnormal{Use Event Tracing to Debug}$
+
+> - As you debug and analyze bugs, you might find event
+ tracing useful.
+
+> - You don't have to recompile, and you can enable events
+ on a running system, which is a plus.
+
+> - Root access is necessary to access the `/sys/kernel/debug`
+ directory and enable events.
+
+```plaintext
+Event Tracing: https://www.kernel.org/doc/html/latest/trace/events.html
+```
+
+> - An example usage is if you are debugging a networking
+ problem, you can enable available events for that area.
+
+> - You can read up on how to use event tracing to get insight
+ into the system.
+
+> - The file `/sys/kernel/debug/tracing/available_events` lists
+ all the events you can enable.
+
+> - You will see several `directories:sched`, `skb` and many
+ others in the `/sys/kernel/debug/tracing/events` directory.
+
+> - You will see a file called `enable` under each of these
+ directories and in the `/sys/kernel/debug/tracing/events`.
+
+> - These directories correspond to kernel areas and trace
+ events they support.
+
+> - These events can be enabled at runtime to get insight into
+ system activity.
+
+> - If you want to enable all skb events:
+
+```sh
+Enable all events:
+ cd /sys/kernel/debug/tracing/events
+ echo 1 > enable
+
+Enable the skb events:
+ cd /sys/kernel/debug/tracing/events/skb
+ echo 1 > enable
+```
+
+> - Before you run your reproducer, enable areas of interest
+ one at a time.
+
+> - You can determine areas of interest based on the call trace.
+
+> - Run the reproducer.
+
+> - You can find the event traces in `/sys/kernel/debug/tracing/trace`.
+
+> - A few debugging tips:
+
+```plaintext
+- Adding additional debug messages (pr_debug or dev_debug)
+ is a good way to gather information on a bug.
+
+- However, avoid adding additional messages and enabling
+ e`vent tracing when debugging a time-sensitive problem,
+ as it can change the timing and could make it harder
+ to reproduce the problem.
+```
+
+> - We will leave you with additional resources to continue
+ your self study on learning to `hunt bugs`, `bisecting a bug`,
+ learn about debug configuration options in the kernel
+ config file, and how to use `dynamic debugging`.
+
+```plaintext
+Hunt Bugs: https://www.kernel.org/doc/html/latest/admin-guide/bug-hunting.html
+Bisecting Bugs: https://www.kernel.org/doc/html/latest/admin-guide/bug-bisect.html
+Dynamic Debugging: https://www.kernel.org/doc/html/latest/admin-guide/dynamic-debug-howto.html
+```
+
+> - Another great resource for looking at the history of
+ changes made to source files is `Contributors to the Linux Kernel`.
+
+```plaintext
+Contributors to the Linux Kernel
+ https://cregit.linuxsources.org/
+
+```
+
+> - Please refer to `Who Made That Change and When: Using Cregit for Debugging`.
+
+```plaintext
+Using Cregit for Debugging
+ http://www.gonehiking.org/ShuahLinuxBlogs/blog/2018/10/18/who-made-that-change-and-when-using-cregit-for-debugging/
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/12-debugging-basics/05-quiz.md b/linux-kernel/course-Linux-Foundation-LFD103/12-debugging-basics/05-quiz.md
new file mode 100644
index 0000000..8b4ca7e
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/12-debugging-basics/05-quiz.md
@@ -0,0 +1,15 @@
+## $\textnormal{Knowledge Check}$
+
+```plaintext
+Which of the following is correct when it comes
+to event tracing?
+ Enabling events requires root access
+ "enable" file allows enable/disable events
+ You can enable all events or selectively enable per sub-system events
+
+Enabling requires root access?
+ True
+
+Adding debug messages helps debug all problems?
+ False
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/01-life-OS-developer.md b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/01-life-OS-developer.md
new file mode 100644
index 0000000..524abff
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/01-life-OS-developer.md
@@ -0,0 +1,68 @@
+## $\textnormal{Life of an Open Source Developer}$
+
+> - Here is my view of the life of an open source
+ developer, derived from my experience as a
+ Linux kernel developer/maintainer.
+
+| Life of an Open Source Developer |
+| -------------------------------- |
+|  |
+
+
+
+> - I consider myself as playing multiple roles at once.
+
+> - I am a new contributor to some areas of the kernel,
+ and, at the same time, an active one in others.
+
+> - I have expertise in some areas and maintain a few of them.
+
+> - I participate in the stable release maintenance
+ process, assisting stable release maintainer(s).
+
+> - Place yourself in the picture on the previous page.
+
+> - Maybe you are in a window shopper role and/or a
+ silent observer role.
+
+> - As you transition to a new contributor, you might
+ choose to wear your user/tester hat for a while,
+ as you get to know the kernel.
+
+> - Many people ask me `“how does one become a maintainer?”`
+ There are many paths to choose from.
+
+> - A few paths that lead you there:
+
+```plaintext
+- Write a new driver.
+- Adopt an orphaned driver or a module (Hint: Check the MAINTAINERS file).
+- Clean up a staging area driver to add it to the mainline.
+- Work towards becoming an expert in an area of your interest by fixing bugs, doing reviews, and making contributions.
+- Find a new feature or an enhancement to an existing feature that is important to the kernel and its ecosystem.
+- Remember that new people bringing new and diverse ideas make the kernel better. We, as a community, welcome and embrace new ideas!
+```
+
+
+
+> - Keep in mind that the maintainer role is hard.
+
+> - It is a very challenging job.
+
+> - However, if you have the tenacity, it is very fulfilling as it
+ gives the best opportunity to change and influence the
+ direction of the kernel and benefit the ecosystem.
+
+> - The power of this role comes with a great responsibility to
+ model and to follow the principles laid out in the Code
+ of Conduct and embrace it.
+
+> - There are several ways you can engage in the kernel development process.
+
+> - Participating in the Stable release process can help you
+ understand how it works, and how fixes flow from the the
+ mainline kernel into stable releases.
+
+> - You can also find problems and report them.
+
+> - Next, we will see how we can go about doing that.
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/02-stable-release-process.md b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/02-stable-release-process.md
new file mode 100644
index 0000000..9bc1e48
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/02-stable-release-process.md
@@ -0,0 +1,32 @@
+## $\textnormal{Participate in Stable Release Process}$
+
+```plaintext
+Stable Release Mailing List: https://subspace.kernel.org/vger.kernel.org.html#stable
+```
+
+> - Stable release maintainers send stable patches for
+ testing with information on where to download the
+ patch from.
+
+> - Below, you can see an example email for reference.
+ Please do not try to use instructions in this email,
+ as this is just an example.
+
+> - This email becomes outdated very quickly.
+
+```plaintext
+ This is the start of the stable review cycle for the 5.2.9 release.
+ There are 144 patches in this series, all will be posted as a response
+ to this one. If anyone has any issues with these being applied, please
+ let me know.
+
+ Responses should be made by Fri 16 Aug 2019 04:55:34 PM UTC.
+ Anything received after that time might be too late.
+
+ The whole patch series can be found in one patch at:
+
+ https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.9-rc1.gz
+ or in the git tree and branch at:
+ git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.2.y
+ and the diffstat can be found below.
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/03-use-the-stable-release-rc-git.md b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/03-use-the-stable-release-rc-git.md
new file mode 100644
index 0000000..d0f743e
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/03-use-the-stable-release-rc-git.md
@@ -0,0 +1,40 @@
+## $\textnormal{Use the Stable Release rc git}$
+
+> - Clone the git repository specified in the email.
+
+> - A new directory `linux-5.2.y` gets created, which
+ contains the kernel sources.
+
+> - Starting out with the distribution configuration
+ file is the safest approach for the very first
+ kernel install on any system.
+
+> - You can do so by copying the configuration for
+ your current kernel from `/boot`.
+
+> - Once this step is complete, it is time to compile
+ the kernel, install the new kernel and run `update-grub`
+ to add the new kernel to the grub menu.
+
+> - Now it is time to reboot the system to boot the newly installed kernel.
+
+```sh
+----------------------------------------------------------------------------------------------------------
+stable_rc_checkout.sh
+ #!/bin/bash
+ ## SPDX-License-Identifier: GPL-2.0
+ # Copyright(c) Shuah Khan
+ #
+ # License: GPLv2
+ # Example usage: stable_rc_checkout.sh
+ mkdir -p stable_rc
+ cd stable_rc
+ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-$1.y
+ cd linux-$1.y
+ #cp /boot/ .config # update script
+ make -j2 all
+ rc=$?; if [[ $rc !=0 ]]; then exit $rc; fi
+ su -c "make modules_install install"
+ echo Ready for reboot test of Linux-$1
+----------------------------------------------------------------------------------------------------------
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/04-download-the-stable-release-patch.md b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/04-download-the-stable-release-patch.md
new file mode 100644
index 0000000..2aa15ce
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/04-download-the-stable-release-patch.md
@@ -0,0 +1,69 @@
+## $\textnormal{Download the Stable Release Patch and Apply the Patch}$
+
+> - Alternately, you can download and apply the patch.
+
+> - The following is my workflow for getting the
+ repository ready, applying the patch, compiling,
+ and installing.
+
+> - Run the `stable_checkout.sh` script once to set
+ up your stable repository.
+
+> - After that, run `pre_compile_setup.sh` to get the
+ patch file and apply whenever a stable release patch
+ is released.
+
+> - I apply patches and use the same repository to be
+ able to detect regressions.
+
+> - I save `dmesg` for the current rc to compare with
+ the next `rc`.
+
+> - Please feel free to make changes to suit your needs.
+
+> - Also, make sure to pass in the correct release
+ information from the stable release emails as arguments
+ to this script.
+
+```sh
+----------------------------------------------------------------------------------------------------------
+stable_checkout.sh
+ #!/bin/bash
+ ## SPDX-License-Identifier: GPL-2.0
+ # Copyright(c) Shuah Khan
+ #
+ # License: GPLv2
+ # Example usage: stable_checkout.sh
+ mkdir -p stable
+ cd stable
+ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux_$1_stable
+ cd linux_$1_stable
+ git checkout linux-$1.y
+ #cp /boot/ .config # update script
+----------------------------------------------------------------------
+
+pre_compile_setup.sh
+ #!/bin/bash
+ ## SPDX-License-Identifier: GPL-2.0
+ # Copyright(c) Shuah Khan
+ #
+ # License: GPLv2
+ # Example usage: pre_compile_setup.sh 5.2.11 1 5
+ # Arg 1 is the stable release version which is typically 5.2.x
+ # Arg2 is the 1 for rc1 or 2 for rc2
+ # Arg3 is 4.x or 5.x used to call wget to get the patch file
+ echo Testing patch-$1-rc$2
+ wget https://www.kernel.org/pub/linux/kernel/v$3.x/stable-review/patch-$1-rc$2.gz ;
+ git reset --hard
+ make clean
+ git pull
+ gunzip patch-$1-rc$2.gz
+ git apply --index patch-$1-rc$2
+ echo "Patch-$1-rc$2 applied"
+ head Makefile
+ make -j2 all
+ rc=$?; if [[ $rc != 0 ]]; then exit $rc; fi
+ su -c "make modules_install install"
+ echo Ready for reboot test of Linux-$1-$2
+---------------------------------------------------------------------------------------------------------
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/05-save-logs-from-current-kernel.md b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/05-save-logs-from-current-kernel.md
new file mode 100644
index 0000000..94a91c8
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/05-save-logs-from-current-kernel.md
@@ -0,0 +1,92 @@
+## $\textnormal{Save the Logs from the Current Kernel}$
+
+> - Now it is time to reboot the system to boot the
+ newly installed kernel.
+
+> - Before we do that, let's save the logs from the
+ current kernel to compare and look for regressions
+ and new errors, if any.
+
+```sh
+dmesg -t > dmesg_current
+dmesg -t -k > dmesg_kernel
+dmesg -t -l emerg > dmesg_current_emerg
+dmesg -t -l alert > dmesg_current_alert
+dmesg -t -l crit > dmesg_current_crit
+dmesg -t -l err > dmesg_current_err
+dmesg -t -l warn > dmesg_current_warn
+```
+
+> - In general, `dmesg` should be clean with no `emerg`,
+ `alert`, `crit`, and `err` level messages.
+
+> - If you see any of these, it might indicate some
+ hardware and/or kernel problem.
+
+```sh
+-----------------------------------------------------------------------------------------------------------------------
+dmesg_checks.sh
+ # !/bin/bash
+ #
+ #SPDX-License-Identifier: GPL-2.0
+ # Copyright(c) Shuah Khan
+ #
+ # License: GPLv2
+
+ if [ "$1" == "" ]; then
+ echo "$0 "
+ exit -1
+ fi
+
+release=`uname -r`
+echo "Start dmesg regression check for $release" > dmesg_checks_results
+
+echo "--------------------------" >> dmesg_checks_results
+
+dmesg -t -l emerg > $release.dmesg_emerg
+echo "dmesg emergency regressions" >> dmesg_checks_results
+echo "--------------------------" >> dmesg_checks_results
+diff $1.dmesg_emerg $release.dmesg_emerg >> dmesg_checks_results
+echo "--------------------------" >> dmesg_checks_results
+
+dmesg -t -l crit > $release.dmesg_crit
+echo "dmesg critical regressions" >> dmesg_checks_results
+echo "--------------------------" >> dmesg_checks_results
+diff $1.dmesg_crit $release.dmesg_crit >> dmesg_checks_results
+echo "--------------------------" >> dmesg_checks_results
+
+dmesg -t -l alert > $release.dmesg_alert
+echo "dmesg alert regressions" >> dmesg_checks_results
+echo "--------------------------" >> dmesg_checks_results
+diff $1.dmesg_alert $release.dmesg_alert >> dmesg_checks_results
+echo "--------------------------" >> dmesg_checks_results
+
+dmesg -t -l err > $release.dmesg_err
+echo "dmesg err regressions" >> dmesg_checks_results
+echo "--------------------------" >> dmesg_checks_results
+diff $1.dmesg_err $release.dmesg_err >> dmesg_checks_results
+echo "--------------------------" >> dmesg_checks_results
+
+dmesg -t -l warn > $release.dmesg_warn
+echo "dmesg warn regressions" >> dmesg_checks_results
+echo "--------------------------" >> dmesg_checks_results
+diff $1.dmesg_warn $release.dmesg_warn >> dmesg_checks_results
+echo "--------------------------" >> dmesg_checks_results
+
+dmesg -t > $release.dmesg
+echo "dmesg regressions" >> dmesg_checks_results
+echo "--------------------------" >> dmesg_checks_results
+diff $1.dmesg $release.dmesg >> dmesg_checks_results
+echo "--------------------------" >> dmesg_checks_results
+
+dmesg -t > $release.dmesg_kern
+echo "dmesg_kern regressions" >> dmesg_checks_results
+echo "--------------------------" >> dmesg_checks_results
+diff $1.dmesg_kern $release.dmesg_kern >> dmesg_checks_results
+echo "--------------------------" >> dmesg_checks_results
+
+echo "--------------------------" >> dmesg_checks_results
+
+echo "End dmesg regression check for $release" >> dmesg_checks_results
+----------------------------------------------------------------------------------------------------------
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/06-additional-steps.md b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/06-additional-steps.md
new file mode 100644
index 0000000..85ae86e
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/06-additional-steps.md
@@ -0,0 +1,33 @@
+## $\textnormal{Additional Steps Before Trying Out the New Kernel}$
+
+> - There are a couple more important steps to take
+ before trying out the newly installed kernel.
+
+> - There is no guarantee that the new kernel will boot.
+
+> - As a safeguard, please ensure that there is at least
+ one good kernel installed.
+
+> - Change the default grub configuration file `/etc/default/grub` to:
+
+```plaintext
+- Enable printing early boot messages to vga using
+ the earlyprink=vga kernel boot option
+
+- Increase the GRUB_TIMEOUT value to 30 seconds,
+ so grub pauses in menu allowing time to choose
+ the kernel to boot from the grub menu, and
+ comment out GRUB_TIMEOUT_STYLE=hidden
+```
+
+```sh
+GRUB_CMDLINE_LINUX="earlyprink=vga"
+#GRUB_TIMEOUT_STYLE=hidden
+GRUB_TIMEOUT=30
+```
+
+> - Run `update-grub` to update the grub configuration in `/boot`:
+
+```sh
+sudo update-grub
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/07-restart-system.md b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/07-restart-system.md
new file mode 100644
index 0000000..a07eeab
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/07-restart-system.md
@@ -0,0 +1,18 @@
+## $\textnormal{Restart the System and Compare Messages}$
+
+> - Now restart the system.
+
+> - Once the new kernel comes up, compare the saved `dmesg`
+ from the old kernel with the new one, and see if there
+ are any regressions.
+
+> - If the newly installed kernel fails to boot, you will
+ have to boot a good kernel, and then investigate why
+ the new kernel failed to boot.
+
+> - Run `Kernel Selftests` and check the results.
+
+```sh
+# Running as root could reboot your system. Run as normal user.
+make kselftest
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/08-improve-documentation.md b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/08-improve-documentation.md
new file mode 100644
index 0000000..a9d700f
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/08-improve-documentation.md
@@ -0,0 +1,26 @@
+## $\textnormal{Enhance the Improve Kernele Documentation}$
+
+> - Enhancing and improving kernel documentation is
+ a good way to engage the Kernel community and
+ learn different areas of the kernel.
+
+> - Ways to learn about the Kernel.
+
+```plaintext
+Preparing to build the documentation
+ There is a script which checks if you have
+ all the needed dependencies to build the documentation.
+
+ This script is called automatically when you run
+ make htmldocs
+
+ Alternatively, you can call the script directly by running:
+ ./scripts/sphinx-pre-install
+
+Building documents and looking for warnings
+ Once you have all the requirements, you can do the building by running:
+ make htmldocs > doc_make.log 2>&1
+
+ Check for warnings and other errors you might find and see if you can fix them.
+ Please keep in mind it is not trivial and/or easy to fix documentation warnings.
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/09-contribute-to-kernel.md b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/09-contribute-to-kernel.md
new file mode 100644
index 0000000..14f5c90
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/09-contribute-to-kernel.md
@@ -0,0 +1,49 @@
+## $\textnormal{Contribute to the Kernel - Getting Started}$
+
+> - There are several ways to get started and contribute to the kernel. A few ideas:
+
+```plaintext
+- Subscribe to the Linux Kernel mailing list for the area of your interest.
+ https://lore.kernel.org/lists.html
+
+- Follow the development activity reading the Linux Kernel Mailing List Archives.
+ https://lore.kernel.org/lists.html
+
+- Join the "#kernelnewbies" IRC channel on the OFTC IRC network. Several
+ of us developers hang out on that channel. This server is home to
+ "#mm", "#linux-rt", and several other Linux channels.
+ https://www.oftc.net/
+
+- Join the "#linux-kselftest", "#linuxtv", "#kernelci", or "#v4l" IRC channels on freenode.
+ https://freenode.net/
+
+ * This server recommends Nick registration. Server Name: "irc.freenode.net/6667".
+ You can register your Nick in the server tab with the command: "identify /msg NickServ identify "
+
+ * You can configure your chat client to auto-identify using the "NickServ(/MSG NickServ+password)" option - works on hexchat.
+
+- Find spelling errors in kernel messages.
+
+- Static code analysis error fixing: Static code analysis is the
+ process of detecting errors and flaws in the source code. The
+ Linux kernel Makefile can be invoked with options to enable
+ to run the Sparse source code checker on all source files, or
+ only on the re-compiled files. Compile the kernel with the
+ source code checker enabled and find errors and fix as needed.
+ https://www.kernel.org/doc/html/latest/dev-tools/sparse.html
+
+- Fix the Syzbot null pointer dereference and WARN bug reports which include
+ the reproducer to analyze. Run the reproducer to see if you can reproduce
+ the problem. Look at the crash report and walk through sources for a
+ possible cause. You might be able to fix problems.
+ https://syzkaller.appspot.com/upstream
+
+- Look for opportunities to add/update .gitignore files for tools and Kselftest.
+ Build tools and Kselftest and run git status. If there are binaries, then it
+ is time to add a new .gitignore file and/or an entry to an existing .gitignore file.
+
+- Run mainline kernels built with the CONFIG_KASAN, Locking debug options
+ mentioned earlier in the debugging section, and report problems if you
+ see any. This gives you an opportunity to debug and fix problems. The
+ community welcomes fixes and bug reports
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/10-quiz.md b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/10-quiz.md
new file mode 100644
index 0000000..2a6f221
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/10-quiz.md
@@ -0,0 +1,9 @@
+## $\textnormal{Knowledge Check}$
+
+```plaintext
+Which of the following are possible ways to participate in the kernel development process?
+ Write Code
+ Improve Documentation
+ Test Kernel Releases
+ Report Bugs
+```
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/images/01-life-of-OS-developer.png b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/images/01-life-of-OS-developer.png
new file mode 100644
index 0000000..48394b7
Binary files /dev/null and b/linux-kernel/course-Linux-Foundation-LFD103/13-kernel-journey/images/01-life-of-OS-developer.png differ
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/14-FAQ/01-FAQ.md b/linux-kernel/course-Linux-Foundation-LFD103/14-FAQ/01-FAQ.md
new file mode 100644
index 0000000..225fc9b
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/14-FAQ/01-FAQ.md
@@ -0,0 +1,5 @@
+## $\textnormal{FAQ}$
+
+| FAQ |
+| --- |
+|  |
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/14-FAQ/images/01-frequently-asked-question.png b/linux-kernel/course-Linux-Foundation-LFD103/14-FAQ/images/01-frequently-asked-question.png
new file mode 100644
index 0000000..0397570
Binary files /dev/null and b/linux-kernel/course-Linux-Foundation-LFD103/14-FAQ/images/01-frequently-asked-question.png differ
diff --git a/linux-kernel/course-Linux-Foundation-LFD103/README.md b/linux-kernel/course-Linux-Foundation-LFD103/README.md
new file mode 100644
index 0000000..b810e0e
--- /dev/null
+++ b/linux-kernel/course-Linux-Foundation-LFD103/README.md
@@ -0,0 +1,16 @@
+# $\textnormal{LFD103 - A Guide to Linux Kernel Development}$
+
+> - This free course introduces developers to the Linux Kernel development
+ process and teaaches the explicit and implicit `rules of the road`. It
+ covers configuring a development system, git basics, writing kernel
+ patches, testing patches, writing commit logs, sending patches, and
+ working on feedback from the kernel community.
+
+> - Link: https://trainingportal.linuxfoundation.org/courses/a-beginners-guide-to-linux-kernel-development-lfd103
+
+> - Helpful links.
+
+```plaintext
+Linux-Next Tree Guide: https://www.kernel.org/doc/man-pages/linux-next.html
+Linux-Mainline Tree Repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
+```
diff --git a/linux-kernel/docs-apt/error-some-index-files-to-download.md b/linux-kernel/docs-apt/error-some-index-files-to-download.md
new file mode 100644
index 0000000..a9985e4
--- /dev/null
+++ b/linux-kernel/docs-apt/error-some-index-files-to-download.md
@@ -0,0 +1,145 @@
+## $\textnormal{Error}$
+
+```sh
+kentlouisetonino@ubuntu xml-ingress (feat/scoped-import) $ sudo apt update
+Hit:1 https://download.docker.com/linux/ubuntu jammy InRelease
+Hit:2 https://brave-browser-apt-release.s3.brave.com stable InRelease
+Hit:3 https://apt.releases.hashicorp.com jammy InRelease
+Hit:4 https://packages.microsoft.com/repos/code stable InRelease
+Hit:5 http://ph.archive.ubuntu.com/ubuntu jammy InRelease
+Hit:6 http://ph.archive.ubuntu.com/ubuntu jammy-backports InRelease
+Get:7 http://ph.archive.ubuntu.com/ubuntu jammy-updates InRelease [128 kB]
+Get:8 http://ph.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages [2,150 kB]
+Get:9 http://ph.archive.ubuntu.com/ubuntu jammy-updates/main i386 Packages [721 kB]
+Get:10 http://ph.archive.ubuntu.com/ubuntu jammy-updates/main Translation-en [368 kB]
+Get:11 http://ph.archive.ubuntu.com/ubuntu jammy-updates/main amd64 DEP-11 Metadata [103 kB]
+Get:12 http://ph.archive.ubuntu.com/ubuntu jammy-updates/restricted amd64 DEP-11 Metadata [212 B]
+Get:13 http://ph.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 Packages [1,135 kB]
+Get:14 http://ph.archive.ubuntu.com/ubuntu jammy-updates/universe i386 Packages [738 kB]
+Get:14 http://ph.archive.ubuntu.com/ubuntu jammy-updates/universe i386 Packages [738 kB]
+Hit:17 https://packages.cloud.google.com/apt cloud-sdk InRelease
+Hit:18 http://security.ubuntu.com/ubuntu jammy-security InRelease
+Ign:14 http://ph.archive.ubuntu.com/ubuntu jammy-updates/universe i386 Packages
+Ign:19 http://ph.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 DEP-11 Metadata
+Get:14 http://ph.archive.ubuntu.com/ubuntu jammy-updates/universe i386 Packages [738 kB]
+Err:14 http://ph.archive.ubuntu.com/ubuntu jammy-updates/universe i386 Packages
+ File has unexpected size (738072 != 738392). Mirror sync in progress? [IP: 202.79.180.254 80]
+ Hashes of expected file:
+ - Filesize:738392 [weak]
+ - SHA256:0252983da206966e9ee855fa4f2b41b0b87dd6858b43537c7a6538ad29e8e847
+ - SHA1:dd0cef917bcdd33d808ec46edbe0dff134320437 [weak]
+ - MD5Sum:b32aebdaf22f885862d89746a3dd44c5 [weak]
+ Release file created at: Fri, 15 Nov 2024 03:50:06 +0000
+Get:19 http://ph.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 DEP-11 Metadata [356 kB]
+Err:19 http://ph.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 DEP-11 Metadata
+
+Hit:21 https://ppa.launchpadcontent.net/obsproject/obs-studio/ubuntu jammy InRelease
+Hit:22 https://esm.ubuntu.com/apps/ubuntu jammy-apps-security InRelease
+Hit:23 https://esm.ubuntu.com/apps/ubuntu jammy-apps-updates InRelease
+Hit:20 https://packagecloud.io/slacktechnologies/slack/debian jessie InRelease
+Hit:24 https://esm.ubuntu.com/infra/ubuntu jammy-infra-security InRelease
+Hit:25 https://esm.ubuntu.com/infra/ubuntu jammy-infra-updates InRelease
+Fetched 128 kB in 2s (58.0 kB/s)
+Reading package lists... Done
+E: Failed to fetch http://ph.archive.ubuntu.com/ubuntu/dists/jammy-updates/universe/binary-i386/Packages.xz File has unexpected size (738072 != 738392). Mirror sync in progress? [IP: 202.79.180.254 80]
+ Hashes of expected file:
+ - Filesize:738392 [weak]
+ - SHA256:0252983da206966e9ee855fa4f2b41b0b87dd6858b43537c7a6538ad29e8e847
+ - SHA1:dd0cef917bcdd33d808ec46edbe0dff134320437 [weak]
+ - MD5Sum:b32aebdaf22f885862d89746a3dd44c5 [weak]
+ Release file created at: Fri, 15 Nov 2024 03:50:06 +0000
+E: Failed to fetch http://ph.archive.ubuntu.com/ubuntu/dists/jammy-updates/universe/dep11/Components-amd64.yml.xz
+E: Some index files failed to download. They have been ignored, or old ones used instead.kentlouisetonino@ubuntu xml-ingress (feat/scoped-import) $ sudo apt update
+Hit:1 https://download.docker.com/linux/ubuntu jammy InRelease
+Hit:2 https://brave-browser-apt-release.s3.brave.com stable InRelease
+Hit:3 https://apt.releases.hashicorp.com jammy InRelease
+Hit:4 https://packages.microsoft.com/repos/code stable InRelease
+Hit:5 http://ph.archive.ubuntu.com/ubuntu jammy InRelease
+Hit:6 http://ph.archive.ubuntu.com/ubuntu jammy-backports InRelease
+Get:7 http://ph.archive.ubuntu.com/ubuntu jammy-updates InRelease [128 kB]
+Get:8 http://ph.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages [2,150 kB]
+Get:9 http://ph.archive.ubuntu.com/ubuntu jammy-updates/main i386 Packages [721 kB]
+Get:10 http://ph.archive.ubuntu.com/ubuntu jammy-updates/main Translation-en [368 kB]
+Get:11 http://ph.archive.ubuntu.com/ubuntu jammy-updates/main amd64 DEP-11 Metadata [103 kB]
+Get:12 http://ph.archive.ubuntu.com/ubuntu jammy-updates/restricted amd64 DEP-11 Metadata [212 B]
+Get:13 http://ph.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 Packages [1,135 kB]
+Get:14 http://ph.archive.ubuntu.com/ubuntu jammy-updates/universe i386 Packages [738 kB]
+Get:14 http://ph.archive.ubuntu.com/ubuntu jammy-updates/universe i386 Packages [738 kB]
+Hit:17 https://packages.cloud.google.com/apt cloud-sdk InRelease
+Hit:18 http://security.ubuntu.com/ubuntu jammy-security InRelease
+Ign:14 http://ph.archive.ubuntu.com/ubuntu jammy-updates/universe i386 Packages
+Ign:19 http://ph.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 DEP-11 Metadata
+Get:14 http://ph.archive.ubuntu.com/ubuntu jammy-updates/universe i386 Packages [738 kB]
+Err:14 http://ph.archive.ubuntu.com/ubuntu jammy-updates/universe i386 Packages
+ File has unexpected size (738072 != 738392). Mirror sync in progress? [IP: 202.79.180.254 80]
+ Hashes of expected file:
+ - Filesize:738392 [weak]
+ - SHA256:0252983da206966e9ee855fa4f2b41b0b87dd6858b43537c7a6538ad29e8e847
+ - SHA1:dd0cef917bcdd33d808ec46edbe0dff134320437 [weak]
+ - MD5Sum:b32aebdaf22f885862d89746a3dd44c5 [weak]
+ Release file created at: Fri, 15 Nov 2024 03:50:06 +0000
+Get:19 http://ph.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 DEP-11 Metadata [356 kB]
+Err:19 http://ph.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 DEP-11 Metadata
+
+Hit:21 https://ppa.launchpadcontent.net/obsproject/obs-studio/ubuntu jammy InRelease
+Hit:22 https://esm.ubuntu.com/apps/ubuntu jammy-apps-security InRelease
+Hit:23 https://esm.ubuntu.com/apps/ubuntu jammy-apps-updates InRelease
+Hit:20 https://packagecloud.io/slacktechnologies/slack/debian jessie InRelease
+Hit:24 https://esm.ubuntu.com/infra/ubuntu jammy-infra-security InRelease
+Hit:25 https://esm.ubuntu.com/infra/ubuntu jammy-infra-updates InRelease
+Fetched 128 kB in 2s (58.0 kB/s)
+Reading package lists... Done
+E: Failed to fetch http://ph.archive.ubuntu.com/ubuntu/dists/jammy-updates/universe/binary-i386/Packages.xz File has unexpected size (738072 != 738392). Mirror sync in progress? [IP: 202.79.180.254 80]
+ Hashes of expected file:
+ - Filesize:738392 [weak]
+ - SHA256:0252983da206966e9ee855fa4f2b41b0b87dd6858b43537c7a6538ad29e8e847
+ - SHA1:dd0cef917bcdd33d808ec46edbe0dff134320437 [weak]
+ - MD5Sum:b32aebdaf22f885862d89746a3dd44c5 [weak]
+ Release file created at: Fri, 15 Nov 2024 03:50:06 +0000
+E: Failed to fetch http://ph.archive.ubuntu.com/ubuntu/dists/jammy-updates/universe/dep11/Components-amd64.yml.xz
+E: Some index files failed to download. They have been ignored, or old ones used instead.
+```
+
+
+
+> - Below are the following reasons this issue happens:
+
+```plaintext
+(1) Mirror Sync Issue
+ - Ubuntu software repositories are hosted on multiple mirrors
+ to make download faster and more reliable.
+ - Sometimes, when a mirror updates its files, there can be a
+ brief period where file sizes and checksums (used to verify
+ file integrity) don't match the expected values.
+ - This is what the "File has unexpected size" error - it
+ occured because the mirror was still in the middle of sync
+ files.
+
+(2) Resolving the Issue by Switching Mirrors
+ - Changing to a different mirror or to the main server allows
+ you to access a server that isn't affected by the sync issue.
+ - Since not all mirrors update at the same time, another server
+ may already have the correct versions of the files, will all
+ sizes and checksums matching.
+
+(3) Clearing Cached Lists
+ - Deleting the cached lists "/var/lib/apt/lists/*" forces "apt"
+ to redownload fresh package lists.
+ - This helps ensure that outdated or corrupted lists from
+ previous updates don't interfere.
+```
+
+> - This issue is usually rare and brief.
+
+> - Once the original mirror completes its sync, it should also work
+ again without issues.
+
+> - References:
+
+```plaintext
+Ubuntu Community Help Wiki:
+ https://help.ubuntu.com/community/AptGet/Howto
+
+Ubuntu Mirrors Documentation:
+ https://wiki.ubuntu.com/Mirrors
+```
diff --git a/linux-kernel/docs-qemu/README.md b/linux-kernel/docs-qemu/README.md
new file mode 100644
index 0000000..9f5a3d6
--- /dev/null
+++ b/linux-kernel/docs-qemu/README.md
@@ -0,0 +1,7 @@
+## QEMU
+
+> - A generic and open source machine emulator and virtualizer.
+
+```plaintext
+https://www.qemu.org/
+```
diff --git a/linux-kernel/docs-snapcraft/deployment.md b/linux-kernel/docs-snapcraft/deployment.md
new file mode 100644
index 0000000..8279656
--- /dev/null
+++ b/linux-kernel/docs-snapcraft/deployment.md
@@ -0,0 +1,24 @@
+## $\textnormal{Deployment Guides}$
+
+```sh
+# Manually compile the C exetuable.
+gcc -o app src/app.c
+
+# Run the multipass.
+sudo systemctl restart snap.multipass.multipassd.service
+
+# Login to snapcraft.
+snapcraft login
+
+# Register the app.
+snapcraft register app-name
+
+# Remove cache.
+snapcraft clean
+
+# Build the snap binary with debug flag.
+snapcraft --debug
+
+# Push the app.
+snapcraft push app-name__amd64.snap --release=stable
+```