On Tue, Dec 14, 2010 at 2:47 PM, Matt Mackall <[email protected]> wrote: > On Tue, 2010-12-14 at 14:33 -0800, Mike Waychison wrote: >> On Tue, Dec 14, 2010 at 2:06 PM, Matt Mackall <[email protected]> wrote: >> > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
