3rd-party/linux-kernel-module-cheat
1
0
Fork 0
mirror of https://github.com/cirosantilli/linux-kernel-module-cheat.git synced 2026-01-29 21:14:27 +01:00
Code Issues Releases Wiki Activity

make getting started first

Browse Source
This commit is contained in:
Ciro Santilli 六四事件 法轮功
2018-10-28 00:00:00 +00:00
parent d80c9ccee2
commit 6c86f27c91
1 changed files with 43 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files

85
README.adoc
View File

@@ -15,51 +15,13 @@ TL;DR: <<qemu-buildroot-setup-getting-started>>
toc::[] toc::[]
== About
This project was created to help me understand, modify and test low level system components by using system simulators.
System simulators are cool compared to real hardware because they are:
* free
* make experiments highly reproducible
* give full visibility to the system: you can inspect any byte in memory, or the state of any hardware register. The laws of physics sometimes get in the way when doing that for real hardware.
The current components we focus the most on are:
* <<linux-kernel>> and Linux kernel modules
* full systems emulators, currently <<qemu-buildroot-setup,qemu>> and <<gem5-buildroot-setup,gem5>>
* <<buildroot>>. We use and therefore document, a large part of its feature set.
The following components are not covered, but they would also benefit from this setup, and it shouldn't be hard to add them:
* C standard libraries
* compilers. Project idea: add a new instruction to x86, then hack up GCC to actually use it, and make a C program that generates it.
The design goals are to provide setups that are:
* highly automated: "just works"
* thoroughly documented: you know what "just works" means
* can be fully built from source: to give visibility and allow modifications
* can also use <<prebuilt, prebuilt binaries>> as much as possible: in case you are lazy or unable to build from source
== Getting started == Getting started
There are several different possible setups to use this repo. Each child section describes a possible different setups for this repo.
If you don't know which one to go for, start with <<qemu-buildroot-setup>>. If you don't know which one to go for, start with <<qemu-buildroot-setup-getting-started>>.
Each child section of this section describes one of those setups, and the trade-offs of each. of this section describes one of those setups, and the <<setup-trade-offs,trade-offs>> of each.
The trade-offs are basically a balance between:
* speed ans size: how long and how much disk space do the build and run take?
* visibility: can you GDB step debug everything and read source code?
* modifiability: can you modify the source code and rebuild a modified version?
* portability: does it work on a Windows host? Could it ever?
* accuracy: how accurate does the simulation represent real hardware?
* compatibility: how likely is is that all the components will work well together: emulator, compiler, kernel, standard library, ...
* guest software availability: how wide is your choice of easily installed guest software packages? See also: <<linux-distro-choice>>
=== QEMU Buildroot setup === QEMU Buildroot setup
@@ -11375,6 +11337,46 @@ TODO: generalize that so that people can upload to their forks.
=== Design rationale === Design rationale
==== Design goals
This project was created to help me understand, modify and test low level system components by using system simulators.
System simulators are cool compared to real hardware because they are:
* free
* make experiments highly reproducible
* give full visibility to the system: you can inspect any byte in memory, or the state of any hardware register. The laws of physics sometimes get in the way when doing that for real hardware.
The current components we focus the most on are:
* <<linux-kernel>> and Linux kernel modules
* full systems emulators, currently <<qemu-buildroot-setup,qemu>> and <<gem5-buildroot-setup,gem5>>
* <<buildroot>>. We use and therefore document, a large part of its feature set.
The following components are not covered, but they would also benefit from this setup, and it shouldn't be hard to add them:
* C standard libraries
* compilers. Project idea: add a new instruction to x86, then hack up GCC to actually use it, and make a C program that generates it.
The design goals are to provide setups that are:
* highly automated: "just works"
* thoroughly documented: you know what "just works" means
* can be fully built from source: to give visibility and allow modifications
* can also use <<prebuilt, prebuilt binaries>> as much as possible: in case you are lazy or unable to build from source
==== Setup trade-offs
The trade-offs between the different <<getting-started,setups>> are basically a balance between:
* speed ans size: how long and how much disk space do the build and run take?
* visibility: can you GDB step debug everything and read source code?
* modifiability: can you modify the source code and rebuild a modified version?
* portability: does it work on a Windows host? Could it ever?
* accuracy: how accurate does the simulation represent real hardware?
* compatibility: how likely is is that all the components will work well together: emulator, compiler, kernel, standard library, ...
* guest software availability: how wide is your choice of easily installed guest software packages? See also: <<linux-distro-choice>>
==== Resource tradeoff guidelines ==== Resource tradeoff guidelines
Choosing which features go into our default builds means making tradeoffs, here are our guidelines: Choosing which features go into our default builds means making tradeoffs, here are our guidelines:
@@ -11425,7 +11427,6 @@ We haven't found the ultimate distro yet, here is a summary table of trade-offs
|y (6) |y (6)
|400 (7) |400 (7)
|Alpine Linux 3.8.0 |Alpine Linux 3.8.0
|y |y
|n (1) |n (1)