[TUHS] kernel boots kernel in 1977

[Warner Losh]

On Thu, Sep 19, 2024, 1:05 AM Bakul Shah via TUHS <tuhs at tuhs.org> wrote:

> Can you not avoid resetting the machine? This can be treated almost as
> sleep in the old kernel, wakeup in the new one! You do have to reset
> devices individually (which may not always work if it requires assistance
> from some undocumented firmware).
>

Kexec does just this. The new kernel boots without going through the reset
vector. The old kernel keeps a tiny bit of code around that tears down all
the protections, etc and hands off to the new kernel a mostly reset
machine.. but it doesn't go through the firmware to do it... it was the
original reason for it in linux: fast reboot times.

Warner

On Sep 18, 2024, at 4:58 PM, ron minnich <rminnich at gmail.com> wrote:
>
> well, yes, on many systems, there's a lot that runs before the kernel. But
> if you have a risc-v system with oreboot, you own the system. The problem
> is that on most of these systems a reset will stop the dram clock for a
> little bit, or glitch clock enable, or dram power, or whatever. New systems
> are not designed to allow this.
>
> Ideally, we could force a reset of everything save memory, but modern
> systems are not designed in this way. Most annoying.
>
> On Wed, Sep 18, 2024 at 4:38 PM Bakul Shah <bakul at iitbombay.org> wrote:
>
>> I would prefer old kernel to new kernel handoff if it can be made to work
>> reliably. Nowadays there are a lot of things that run before the kernel
>> gets control.
>>
>> On Sep 18, 2024, at 3:38 PM, ron minnich <rminnich at gmail.com> wrote:
>>
>> Interesting about the amiga. I'm assuming their firmware zeros memory on
>> reset, so you have to do handoff from kernel to kernel, not via a reset and
>> so on?
>>
>> What was particularly nice about the V6/PDP-11 case: we were able to yank
>> reset, which let us cleanly reset/disable devices, because everything was
>> in memory when we got back. I miss the simplicity of the old machines.
>>
>> On Wed, Sep 18, 2024 at 3:07 PM Christian Hopps <chopps at chopps.org>
>> wrote:
>>
>>>
>>> We had/have this functionality in the Amiga port of NetBSD.
>>>
>>> It is implemented as `/dev/reload` device and you copy a kernel image to
>>> it. In locore.s there's code that copies the kernel image over top of the
>>> running kernel and then restarts. I believe for it to work nothing below
>>> the copy code in locore.s can change :)
>>>
>>> Thanks,
>>> Chris.
>>>
>>> Phil Budne <phil at ultimate.com> writes:
>>>
>>> > ron minnich wrote:
>>> >> But I'm wondering: is Ed's work in 1977 the first "kernel boots
>>> kernel" or
>>> >> was there something before?
>>> >
>>> > There was!  The PDP-7 UNIX listings contain a program trysys.s
>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/trysys.s
>>> > that reboots the system by reading a.out into user memory (in the high
>>> > 4K of core), then copies it to low memory and jumping to the entry
>>> > point.  The name suggests its original intended use was to test a new
>>> > system (kernel).
>>> >
>>> > P.S.
>>> > Normal bootable system images seem to have been stored in reserved
>>> > tracks of the (fixed head) disk (that are inacessible via system
>>> calls):
>>> >
>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/maksys.s
>>> > reads a.out and uses I/O instructions to write it out.
>>> >
>>> > P.P.S.
>>> > Accordingly, I put together a "paper tape" for booting the system:
>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/pbboot.s
>>> >
>>> > P.P.P.S.
>>> > The system (kernel) is 3K words, the last 1K of low memory
>>> > used for the character table for the vector graphics controller.
>>> >
>>> > The definitions for the table are compiled by
>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/cas.s
>>> > from definition file
>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/cas.in
>>> > (after, ISTR, figuring out the ordering of the listing pages!)
>>> >
>>> > I don't think we ever figured out how the initial character table
>>> > is loaded into core.  One thing that was missing from the table
>>> > was the dispatch array, which I recreated:
>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/chrtbl.s
>>> >
>>> > The system (kernel) could be built for a "cold start", reloading the
>>> > disk (prone to head crashes?) from paper tape? But I don't think
>>> > anyone ever reconstructed the procedure for rebuilding a disk that way.
>>> >
>>> > The disk was two sided, and the running system only used one side:
>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dsksav.s
>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dskres.s
>>> > appear to be programs to save and restore the filesystem from the
>>> > "other" side of the disk.
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20240919/dbffb365/attachment.htm>