4 ms·

On a practical note, testing a system's ability to start up is usually much faster and easier than testing its ability to work properly for long periods of time

On a practical note, testing a system's ability to start up is usually much faster and easier than testing its ability to work properly for long periods of time. Real-world long-term behavior is unpredictable and somewhat chaotic, but there are only so many things you can do straight out of a reboot.

josephg 4y ago
This is food for thought. I wonder if there’s some other ways we could architect operating systems so these problems wouldn’t manifest as much? Like, the “startup process” seems to be framed wrong to me. Why does it take tens of billions of clock cycles (seconds) to start up? Essentially all the system is doing is filling some memory with a known-good kernel image, and initialising some hardware devices. If we think about startup as “restoring a (deterministic) boot image”, then booting is much faster. And we might be able to use that to verify the kernel’s integrity periodically and maybe restore parts of that image at runtime if the system ends up in an invalid state. Sort of a “soft / partial reboot” process. In my testing code I make heavy use of check() methods. These methods go through all my runtime invariants and checks that they all still hold. This is fantastically useful in testing - a check method and a fuzzer do the work of 10x their weight in unit tests. I wonder if a similar method in the kernel (run every hour or something) could be used to find and track down bugs, and automatically recover when they’re found. “Oh the USB device is in an invalid state. Log and reset it!”.
- semitones 4y ago
  To better understand why we can't just load a snapshot of the "desired" memory state directly from a cached image, we have to understand what the OS actually does during it's initialization. One of the main responsibilities of the OS is to manage hardware resources. During init, kernel drivers and modules perform health checks and determine availability and status of hardware resources, peripherals, I/O, etc. Since lots of things could go wrong with the various hardware components, at anytime, this process should be performed during each system boot.
  - feanaro 4y ago
    Your reasoning doesn't invalidate the soft reboot concept. It merely states that having soft reboot would not allow us to get rid of hard reboot, which I agree with.
    - josephg 4y ago
      Exactly. If there’s benefit in checking that everything is configured correctly, and software bugs, hardware bugs and cosmic rays cause things to enter a misconfigured state, then maybe it’s worth periodically validating the internal state at runtime? The earlier errors are detected, the less damage they can cause and the easier they are to debug. Also when errors are detected, I imagine soft-reboots of that hardware or kernel module would usually be better for the user than hard reboots of the entire system. Mind you, a once in a blue moon reboot of the network interface might cause more problems in a web application than a reboot of the entire machine.

josephg 4y ago

This is food for thought. I wonder if there’s some other ways we could architect operating systems so these problems wouldn’t manifest as much? Like, the “startup process” seems to be framed wrong to me. Why does it take tens of billions of clock cycles (seconds) to start up? Essentially all the system is doing is filling some memory with a known-good kernel image, and initialising some hardware devices. If we think about startup as “restoring a (deterministic) boot image”, then booting is much faster. And we might be able to use that to verify the kernel’s integrity periodically and maybe restore parts of that image at runtime if the system ends up in an invalid state. Sort of a “soft / partial reboot” process. In my testing code I make heavy use of check() methods. These methods go through all my runtime invariants and checks that they all still hold. This is fantastically useful in testing - a check method and a fuzzer do the work of 10x their weight in unit tests. I wonder if a similar method in the kernel (run every hour or something) could be used to find and track down bugs, and automatically recover when they’re found. “Oh the USB device is in an invalid state. Log and reset it!”.

semitones 4y ago
To better understand why we can't just load a snapshot of the "desired" memory state directly from a cached image, we have to understand what the OS actually does during it's initialization. One of the main responsibilities of the OS is to manage hardware resources. During init, kernel drivers and modules perform health checks and determine availability and status of hardware resources, peripherals, I/O, etc. Since lots of things could go wrong with the various hardware components, at anytime, this process should be performed during each system boot.
- feanaro 4y ago
  Your reasoning doesn't invalidate the soft reboot concept. It merely states that having soft reboot would not allow us to get rid of hard reboot, which I agree with.
  - josephg 4y ago
    Exactly. If there’s benefit in checking that everything is configured correctly, and software bugs, hardware bugs and cosmic rays cause things to enter a misconfigured state, then maybe it’s worth periodically validating the internal state at runtime? The earlier errors are detected, the less damage they can cause and the easier they are to debug. Also when errors are detected, I imagine soft-reboots of that hardware or kernel module would usually be better for the user than hard reboots of the entire system. Mind you, a once in a blue moon reboot of the network interface might cause more problems in a web application than a reboot of the entire machine.