From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
Date: Sat,  2 Jan 2010 13:18:54 -0600
Message-ID: <b2d3848d1001021118m2d3ad0f1y8fed751faadee451@mail.gmail.com>
From: mycroftiv 9gridchan <mycroftiv@sphericalharmony.com>
To: 9fans@9fans.net
Content-Type: text/plain; charset=UTF-8
Subject: [9fans] Announcing: rootless post kernel load startup
Topicbox-Message-UUID: b605e79c-ead5-11e9-9d60-3106f5b1d025

>would the dead processes include everything but the boot-time
>helpers?  from the perspective of any users of the system, wouldn't
>this be equivalent to a reboot?

>have you tested rebooting either machine while the other is
>running?  have you tested a three machine scenario?
>this reminds me of nfs cross mounting.  how is this different?

Thanks for your interest. Certainly, if the file descriptors being
used by your active applications die, those apps are pretty much dead.
The question of why the scenario is an improvement on rebooting
depends on the specifics - one answer is that in the usage model I
find most optimal, I like to base what I regard as the most essential
services, including the cpu -R listener, either out of boot or a
ramfs, so the system remains available for remote dial-in and
administration. I find that being able to drawterm in, mount sources
for access to the full disttribution, and then work to reset/repair
and environment is a lot more pleasant than plugging in a monitor to a
box I prefer to run headless and then rebooting and hoping that the
issues that forced the reboot (such as unavailable network resources)
are in good enough shape to get things put back together.

The example I gave of starting venti then rooting from a remote fossil
using that venti isn't a particularly important specifically, I simply
wanted to illustrate the fact that moving to a more interactive and
configurable post kernel load boot sequence creates additional
possibilities. The initial motivation was simply that with a grid that
uses separate venti, fossil, and cpu, the imposed boot order
dependency and the fact that the loss of one server could make the
others later in the chain unusable even though they still had running
kernels and control of the hardware seemed suboptimal. I love the
ability to distribute system components, but I wanted to be able to
keep interacting with my cpu server even if I needed to reboot the
fossil.

However, I don't want to seem defensive, and these bootup modification
patches are not anything I want to try to claim as the best possible
system. Just on the technical level the plan9rc I'm using doesn't
cover 100% of the cases handled by the standard tools - it assumes the
only types of disk drives in the world are sdC0, C1, D0, D1 at the
moment, for instance.

~mycroftiv