On Tue, Dec 14, 2010 at 2:47 PM, Matt Mackall [off-list ref] wrote:

On Tue, 2010-12-14 at 14:33 -0800, Mike Waychison wrote:

quoted

On Tue, Dec 14, 2010 at 2:06 PM, Matt Mackall [off-list ref] wrote:

quoted

What happens if you oops before userspace is available?

Either one of two general cases:
  - The crash is a one-off and the machine comes back.  The boot
number sequence will see a hole in it, which is a clue that something
bad happened.
  - The machine is in a crash loop.  This has the same failure mode
for us as if the machine never made it onto the network due to
whatever reason: bad cables, bad firmware, bad ram, ...

In both cases, we can detect that something is wrong and handle it.
Note that our firmware is responsible for incrementing the boot
sequence at bootup, which is why the above works.   In general though,
our machines do make it up to userland -- staying alive once booted is
the hard part ;)

Interesting. Is this Google-specific firmware magic?

Ya, this is a Google-ism.  I'd be surprised if there weren't other
platforms that had the same thing though (though I don't know of
anything standard on x86).

I'd probably accept
a hook in random.c to fold a number into the UUID, which would unify
things.

I'm not sure there is a _good_ way to support this, is there?  I just
read through RFC 4122 and UUIDs seem to be pretty well structured;
it's probably not such a great idea to allow folks to override
portions of it.  Like I mentioned in my last email though, I'm okay
pushing this boot sequence ID down into the user blob which acts like
a place for "vendor extensions" if there isn't a good place for it in
the kernel.