Re: [TUHS] reboot(2) system call

["Greg A. Woods" <woods@robohack.ca>]

[-- Attachment #1: Type: text/plain, Size: 2107 bytes --]

At Mon, 1 Feb 2021 19:30:47 -0700, Warner Losh <imp@bsdimp.com> wrote:
Subject: Re: [TUHS] reboot(2) system call
>
> Would be nice to know which one so I can go check. I've not seen leaked
> xenix code though, so it may be possible.

Well the first versions I used were on 286 machines, and then 386.

I think there may be binaries available in the darker corners (maybe
even on archive.org) if one wanted to test empirically on either
emulation or real hardware.  Maybe someday I could do that, but not
soon.

On a related note, one of the weird things about Unix System V, from the
beginning more or less, and right up to and including the last SysVr4,
the shutdown scripts use "sync; sync; sync" all on one line like that
(on r4 they use the full path to "/sbin/sync", but still three times).
I think on some versions the subsequent call will block briefly while
the first call finishes scheduling buffer writes (i.e. the call will
wait instead of just returning if another process is in the critical
section), they all still just schedule async writes.

If I'm not mistaken though calling "sync" in any way at all shouldn't
normally be necessary during a proper shutdown as all filesystems,
including the root fs, will be unmounted during the process, thus
forcing all dirty buffers to be flushed first, and this is in fact the
case from SysVr3 and on (i.e. after uadmin(2) with A_SHUTDOWN was
introduced).  Also, on SysVr4 the fsflush daemon runs as a kernel daemon
process, so if I understand correctly it isn't killed during shutdown or
in single user mode, thus it'll still be doing the equivalent of sync(2)
right up to the end.

On the other hand in the particular SysVr4-i386 version I have the code
that would actually wait for all async buffer writes during umounts,
i.e. in bdwait(), is commented out and replaced by a "delay(200)".  I
can't imagine why, nor can I imagine trying to debug that without source!

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]