[TUHS] Re: kernel boots kernel in 1977

On Wed, Sep 18, 2024 at 8:05 PM Bakul Shah via TUHS <tuhs(a)tuhs.org> wrote: Perhaps this is what you mean when you mention assistance from firmware, Bakul, but it may be useful to consider that _many_ devices are touched by e.g. a BIOS or UEFI or whatever well before the OS is even loaded. If one steps back and considers the utility of a BIOS/UEFI (and I often lump these into the same category), there are three principal reasons for it: 1) back in the bad old days, we could offload common IO functions into code stored on a ROM, freeing up precious RAM for programs. 2) firmware provides a layer of indirection between the system and the host software, allowing both to vary while continuing to work with newer versions of the other. And finally 3) firmware facilitates bootstrapping the system by providing the host some way to access devices and locate and load an OS image, er, before the OS image is loaded. SOMETHING has to get enough code loaded from somewhere to start the system; often times that's firmware. Anyway, the last two suggest that device state can be arbitrarily munged before the OS takes over, and an actual reset at the device level might wipe out some state the OS depends on. Consider, for example, programming PCI BARs; on a "modern" x86-64 system with UEFI, this is done by firmware in the PEI layer, and the OS may expect that to already be set up by the time it is probing buses. An actual honest-to-goodness reset will probably wipe the BARs, requiring the host OS to program them (ironically, many OSes are already equipped to do so, as they have to handle these cases for e.g. PCI hotplug events, though many don't do it in the "ordinary" discovery and initialization phase of boot). I suppose the point is that a reset is great because it really does wipe out state, but it may also be a bummer because, well, it really does wipe out state. :-) - Dan C.