So my question here about SPARC versus x86 is, can we pre-approve the
SPARC project in this ARC case, and allow for phased delivery to deliver
phase II? (Just thinking about minimizing the number of times the
project team has to come back to ARC, especially when adding in SPARC
support should be a no-brainer at least as far as ARC is concerned.)
I'll grant you that I *suspect* the post-panic fast reboot case probably
is more complicated, and probably will need a case of its own.
-- Garrett
Sherry Moore wrote:
> Hi Joe,
>
>
>>> -e If -f is present, reboot to the specified boot |
>>> environment. |
>>>
>>>
>> "boot environment" doesn't seem to have a clear definition here.
>>
>
> How about
>
> If -f is present, reboot to the specified boot environment (BE)
> as created by lucreate(1M).
>
>
>>> -f Fast reboot bypassing firmware and boot loader. The
>>> |
>>> new kernel will be loaded into memory by the running
>>> |
>>> kernel, and control will be transferred to the loaded |
>>> kernel. If disk or kernel arguments are specified, |
>>> they must be specified before other boot arguments. |
>>> See Example 3 for details. |
>>> |
>>> Currently only available on x86 system. |
>>>
>>>
>> The x86 disclaimer seems worthy of a place in the actual proposal and a
>> short justification.
>>
>
> This is what I put in section 3.1 of
>
> http://sac/Archives/CaseLog/arc/PSARC/2008/382/materials/onepager.txt
>
> ============================================================================
> To make the project more manageable and still deliver value on
> their own, the problem described above can be solved in the
> following phases:
>
> Phase I: Fast Reboot on x86 platforms.
> Phase II: Fast Reboot post panic on x86 platforms.
> Fast Reboot (normal and post panic) on SPARC
> platforms.
>
> Phase II of the project will likely require
> some form of memory DR where a minimum amount
> of clean memory is used to bring up the kernel
> while the rest of the memory is tested and
> brought in dynamically.
>
> This case delivers phase I.
> ============================================================================
>
> Does that seem sufficient to you?
>
> Garrett asked a similar question before, "Why can't the SPARC support
> be done in parallel?" The answer is basically that, "It can, but I am
> kind of single-threaded". :)
>
> Thanks much,
> Sherry
>
