Being the hardcore person who fully understands an important complex system such as a computer, it does have a nice ring to it doesn’t it?
+
+
+
But before you dedicate your life to this nonsense, do consider the following points:
+
+
+
+
+
almost all contributions to the kernel are done by large companies, and if you are not an employee in one of them, you are likely not going to be able to do much.
+
+
This can be inferred by the fact that the devices/ directory is by far the largest in the kernel.
+
+
+
The kernel is of course just an interface to hardware, and the hardware developers start developing their kernel stuff even before specs are publicly released, both to help with hardware development and to have things working when the announcement is made.
+
+
+
Furthermore, I believe that there are in-tree devices which have never been properly publicly documented. Linus is of course fine with this, since code == documentation for him, but it is not as easy for mere mortals.
+
+
+
There are some less hardware bound higher level layers in the kernel which might not require being in a hardware company, and a few people must be living off it.
+
+
+
But of course, those are heavily motivated by the underlying hardware characteristics, and it is very likely that most of the people working there were previously at a hardware company.
+
+
+
In that sense, therefore, the kernel is not as open as one might want to believe.
it is impossible to become rich with this knowledge.
+
+
This is partly implied by the fact that you need to be in a big company to make useful low level things, and therefore you will only be a tiny cog in the engine.
+
+
+
The key problem is that the entry cost of hardware design is just too insanely high for startups in general.
+
+
+
+
Is learning this the most useful thing that you think can do for society?
+
+
Or are you just learning it for job security and having a nice sounding title?
First determine the useful goal, and then backtrack down to the most efficient thing you can do to reach it.
+
+
+
+
there are two things that sadden me compared to physics-based engineering:
+
+
+
+
+
+
you will never become eternally famous. All tech disappears sooner or later, while laws of nature, at least as useful approximations, stay unchanged.
+
+
+
every problem that you face is caused by imperfections introduced by other humans.
+
+
It is much easier to accept limitations of physics, and even natural selection in biology, which is are produced by a sentient being (?).
+
+
+
+
+
+
+
+
Physics-based engineering, just like low level hardware, is of course completely closed source however, since wrestling against the laws of physics is about the most expensive thing humans can do.
+
+
+
+
+
+
Are you fine with those points, and ready to continue wasting your life with this crap?
+
+
+
Good. In that case, read on, and let’s have some fun together ;-)
Besides a seamless initial build, this project also aims to make it effortless to modify and rebuild several major components of the system, to serve as an awesome development setup.
While hacking QEMU, you will likely want to GDB step its source. That is trivial since QEMU is just another userland program like any other, but our setup has a shortcut to make it even more convenient, see: Section 18.8, “Debug the emulator”.
In order to test the kernel and emulators, userland content in the form of executables and scripts is of course required, and we store it mostly under:
If you are lazy to built the Buildroot toolchain and QEMU, but want to run e.g. ARM Userland assembly in User mode simulation, you can get away on Ubuntu 18.04 with just:
After doing that setup, you can already execute your userland programs from inside QEMU: the only missing step is how to rebuild executables and run them.
./build user-mode-qemu first builds Buildroot, and then runs ./build-userland, which is further documented at: Section 1.7, “Userland setup”. It also builds QEMU. If you ahve already done a QEMU Buildroot setup previously, this will be very fast.
+
./build user-mode-qemu first builds Buildroot, and then runs ./build-userland, which is further documented at: Section 1.8, “Userland setup”. It also builds QEMU. If you ahve already done a QEMU Buildroot setup previously, this will be very fast.
If you modify the userland programs, rebuild simply with:
@@ -8849,7 +8947,7 @@ Program aborted at tick 0
-
we would have to think how to not have to include the kernel modules twice in the root filesystem, but still have 9P working for fast development as described at: Section 1.1.2.2, “Your first kernel module hack”
+
we would have to think how to not have to include the kernel modules twice in the root filesystem, but still have 9P working for fast development as described at: Section 1.2.2.2, “Your first kernel module hack”
Userland assembly content is located at: Section 22, “Userland assembly”. It was split from this section basically because we were hitting the HTML h6 limit, stupid web :-)
@@ -29439,7 +29537,7 @@ cd ../..
This content makes up the bulk of the userland/ directory.
However, since the rootfs_overlay directory does not require compilation, unlike say kernel modules, we also make it 9P available to the guest directly even without ./copy-overlay at:
Being the hardcore person who fully understands an important complex system such as a computer, it does have a nice ring to it doesn’t it?
-
-
-
But before you dedicate your life to this nonsense, do consider the following points:
-
-
-
-
-
almost all contributions to the kernel are done by large companies, and if you are not an employee in one of them, you are likely not going to be able to do much.
-
-
This can be inferred by the fact that the devices/ directory is by far the largest in the kernel.
-
-
-
The kernel is of course just an interface to hardware, and the hardware developers start developing their kernel stuff even before specs are publicly released, both to help with hardware development and to have things working when the announcement is made.
-
-
-
Furthermore, I believe that there are in-tree devices which have never been properly publicly documented. Linus is of course fine with this, since code == documentation for him, but it is not as easy for mere mortals.
-
-
-
There are some less hardware bound higher level layers in the kernel which might not require being in a hardware company, and a few people must be living off it.
-
-
-
But of course, those are heavily motivated by the underlying hardware characteristics, and it is very likely that most of the people working there were previously at a hardware company.
-
-
-
In that sense, therefore, the kernel is not as open as one might want to believe.
it is impossible to become rich with this knowledge.
-
-
This is partly implied by the fact that you need to be in a big company to make useful low level things, and therefore you will only be a tiny cog in the engine.
-
-
-
The key problem is that the entry cost of hardware design is just too insanely high for startups in general.
-
-
-
-
Is learning this the most useful thing that you think can do for society?
-
-
Or are you just learning it for job security and having a nice sounding title?
First determine the useful goal, and then backtrack down to the most efficient thing you can do to reach it.
-
-
-
-
there are two things that sadden me compared to physics-based engineering:
-
-
-
-
-
-
you will never become eternally famous. All tech disappears sooner or later, while laws of nature, at least as useful approximations, stay unchanged.
-
-
-
every problem that you face is caused by imperfections introduced by other humans.
-
-
It is much easier to accept limitations of physics, and even natural selection in biology, which is are produced by a sentient being (?).
-
-
-
-
-
-
-
-
Physics-based engineering, just like low level hardware, is of course completely closed source however, since wrestling against the laws of physics is about the most expensive thing humans can do.
-
-
-
-
-
-
Are you fine with those points, and ready to continue wasting your life with this crap?
-
-
-
Good. In that case, read on, and let’s have some fun together ;-)
