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.
At the *very least*, this class of issue should have been included in the 2008/760 one-pager. 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 >> > >
