I am wondering if, since Linux is 100% open-source, it is possible to follow line-by-line instructions of Linux to observe how the OS works entirely, so that one may get a better knowledge of how OSes boot, load processes, manage timesliced processes/multitasking, load drivers, make system calls, operate via APIs, user mode threads accessing drivers, GUI/X Window System connections, and driver-to-driver interactions.

Is it possible to do this from the source, i.e. how feasible is it to linearly trace the source, and is it linear at all?

  • At any one time, one (virtual) CPU core will be executing exactly one machine code instruction, and a single line of source code will map to a (possibly large) number of machine code instructions. So yes, it's technically possible. I don't know how feasible it is in practice, but look up kernel debugging. – a CVn Nov 16 '13 at 22:36
  • define "trace". do you mean trace in the debugging sense (analyzing a live system), or trace in the logical sense (read the code)? – strugee Nov 17 '13 at 10:49
  • In theory, yes, with a lot of work. In practice, it's millions of lines of code, you could spend your life reading them all. – Gilles 'SO- stop being evil' Nov 17 '13 at 20:43

I suspect this is more difficult than fathomed by Michael Kjörling and the OP.

The OP seems to think of the operation of a CPU as a straight, single time-line, where tasks are executed sequentially. And Michael Kjörling re-inforces that impression by remarking that any given core is executing strictly one instruction per cycle, sequentially.

This is certainly incomplete on the microscopic level (present day pcs have multiple CPUs) and unhelpful on the meso/macro-scopic levels.

We describe all complex systems in terms of macroscopic variables; sometimes this is because those are only the variables we have access to, but their usefulness is not principally that of easy access. We do not describe a gas by stating positions and velocities of all particles involved, but use instead pressure/volume/temperature/entropy.

By the same token, we do not characterize a machine state by means of CPU instructions, but in terms of tasks and services being carried out. As such, there are at any one given time multiple processes running and exchanging information, often acting in concert (and sometimes even in competition, sadly) to achieve a common goal.

The equivalent of pressure/volume/entropy/temperature in computer science are the abstraction layers, simplified representations of the tasks performed by a machine, irrespective of the actual realizations of the agents performing the tasks. ALs are present all over computer science, from HALs to the OSI layers, and so on.

Asking for a step-by-step representation of a pc operation is like giving up strange attractors in the theory of turbulence in favor of a multi-particle fluid description. Or trying to decode human genome by studying chemical bonds. One builds on the other, but the new abstraction layer affords insights unimaginable otherwise.


You can view the source code and learn how the system works (if you know C/C++ and assembly well). As far as I am aware, the code is not linear.


Probably most what you can to get is some online debuging and systemd's journald daemon which records everything from very early on (way before traditional logging facilieties).

If that is not enough and you want track system in lower level you can run linux in virtual environment like QEMU, which would allow to see deep in internals, use gdb on live kernel and so on and so on. There is some tutorials how to setup QEMU for live kernel and its entire image debugging: http://www.cs.rochester.edu/~sandhya/csc256/assignments/qemu_linux.html

Also take a look to stackowerflow question for tools inside kernel used for debugging: https://stackoverflow.com/questions/4943857/linux-kernel-live-debugging-how-its-done-and-what-tools-are-used


I'd like to point you to bootchart. bootchart starts as first process instead of init and monitors what is executed and how long it runs.


This is not everything you wanted to monitor, but it has a very nice graphical output and it's worth to try.

To monitor system calls you could for example execute perf record at early boot, but it's up to you how to interpret millions of lines.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.