diff --git a/README.adoc b/README.adoc index 61f87b6..58339bc 100644 --- a/README.adoc +++ b/README.adoc @@ -15,51 +15,13 @@ TL;DR: <> 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: - -* <> and Linux kernel modules -* full systems emulators, currently <> and <> -* <>. 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 <> as much as possible: in case you are lazy or unable to build from source - == 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 <>. +If you don't know which one to go for, start with <>. -Each child section of this section describes one of those setups, and the 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: <> + of this section describes one of those setups, and the <> of each. === QEMU Buildroot setup @@ -11375,6 +11337,46 @@ TODO: generalize that so that people can upload to their forks. === 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: + +* <> and Linux kernel modules +* full systems emulators, currently <> and <> +* <>. 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 <> as much as possible: in case you are lazy or unable to build from source + +==== Setup trade-offs + +The trade-offs between the different <> 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: <> + ==== Resource tradeoff 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) |400 (7) - |Alpine Linux 3.8.0 |y |n (1)