Dana H. Myers wrote:
> Garrett D'Amore wrote:
>> Hmm... 2008/760 *does* say its enabled by default. That got approved
>> as a fast track. Sounds like there are some issues here.
> That was right before the holidays, I must not have been watching.
>>
>> However, are the problems with this "architectural" in scope, or are
>> they more "bugs" in scope? (I.e. if we got the bugs resolved
>> properly, is there any good reason why the approval of 2008/760
>> shouldn't have been granted?)
>>
>> My gut here says the problems are just bugs (maybe severe ones!), and
>> not a problem with system architecture as a whole. Do I misunderstand?
> What's "just a bug"? Something not working as designed, right? Applying
> this standard, my comments stand - there's an architectural disconnect.
As a litmus test:
If the "design" (at least that part of it to which PSARC has been
exposed) is defective, then its an architectural problem. However, if
the problems can be resolved without changing the interfaces that were
ARC'd, then the problem is "Just a bug".
Note that being a just a bug has nothing to do with complexity or
severity; the issue here is how this piece fits in with the interfaces
that were supplied to ARC.
>
> At the *very least*, this class of issue should have been included in the
> 2008/760 one-pager.
Possibly. Was this problem understood then?
-- Garrett
>
> Dana
>
>>
>> -- Garrett
>>
>> Dana H. Myers wrote:
>>> Garrett D'Amore wrote:
>>>> Dana H. Myers wrote:
>>>>> Jerry Gilliam wrote:
>>>>>> I am submitting the following fast-track on behalf of Sherry
>>>>>> Moore. Minor
>>>>>> release binding is requested. The timeout is set for 02-18-2009.
>>>>>>
>>>>>>
>>>>> As much as I appreciate the convenience of fast reboot,
>>>>> fast reboot is not mature enough to be made the default behavior.
>>>>> See CR 6760313, for the tip of the iceberg. Architecturally, we're
>>>>> cornered in that we're dependent on cooperative ACPI BIOS
>>>>> behavior. If we un-init and re-init the ACPI namespace, we'll
>>>>> run _INI methods more than once on a system that, from the
>>>>> BIOS perspective, hasn't been rebooted. I don't have a satisfactory
>>>>> general answer for this.
>>>>>
>>>>> I believe this case certainly warrants a full discussion.
>>>>
>>>> I do not believe that this case (or any other) has changed the
>>>> default. All this case does is is make an override option
>>>> available to administrators that have manually changed the default.
>>>>
>>>> As such, I don't think a full discussion *on this case* is warranted.
>>>>
>>>> If a case were brought forward intended to change the default
>>>> behavior, I would agree that a full discussion would be warranted.
>>>>
>>> So, I went back and looked at 2008/760, which does indeed
>>> provide the ability to set the default behavior of 'reboot', though the
>>> following sentence in *this* case:
>>>
>>>>>>
>>>>>>
>>>>>> With the introduction of
>>>>>>
>>>>>> 2008/760 Boot configuration Service
>>>>>>
>>>>>> reboot(1M) will behave as "reboot -f", which will bypass the
>>>>>> firmware.
>>>
>>> ... was disturbing. Is the "stock" default behavior of 'reboot' a
>>> PROM reboot? Or is it fast reboot?
>>>
>>> Dana
>>>
>>
>>
>
