[ConsoleKit] extend ConsoleKit to support fast reboot on OpenSolaris x86

[David Zeuthen]

On Wed, Sep 9, 2009 at 11:47 AM, Lennart
Poettering<lennart at poettering.net> wrote:
> On Wed, 09.09.09 11:03, David Zeuthen (zeuthen at gmail.com) wrote:
>
>> > I see it like this: if the user tries to reboot, then probably because
>> > something is really wrong. If computers and their software were
>> > without bugs there would not be a reason to manually reboot
>> > ever. Which is the reason why I think that manually triggered reboot
>> > shuld always be the 'hardest' reset avaiable.
>>
>> I don't agree with this. Lots of developers like to reboot their
>> boxen, for a multitude of reasons, and they shouldn't have to be
>> forced use the slow path. Also, see below.
>
> Developers can always type some flavour of "reboot" in a shell, they
> are not the ones the GNOME UI should cater for.

This still doesn't justify doing "hardest reset" for reboots via
GNOME. I'm not sure why you think that's a good idea. And I doubt it
really matters much in practice since device drivers doesn't rely on
the BIOS initialization to properly use the hardware.... in fact, if
that is the case, we'll get more bug reports by not defaulting to slow
reboot....

>> > OTOH there are automatically triggered reboots, most importantly after
>> > a software upgrade. In this case rebooting is not really a choice
>> > of the user but was asked for by the guy who designed the package that
>> > was upgraded. Because fast boots are actually much much faster than hard
>> > resets in this case the user's work should be disrupted only
>> > minimally, hence a fast reboot is advisable.
>> >
>> > Summary: fast reboots are just nicer to the user, so use them wen it
>> > is safe to use them. Otherwise use full resets.
>>
>> But I think this logic MUST be implemented in reboot(8) / kexec /
>> whatever. E.g. leave the task of properly implementing "fall back to
>> slow reboot if fast reboot doesn't work for whatever reason" [1] to
>> reboot(8) - if you don't then commandline users of reboot(8) will be
>> annoyed _anyway_.
>
> Sure. In the end it should be implemented as another switch for
> shutdown(8). However, that does not mean that CK should not provide a
> D-Bus wrapper around this to make this available for user services
> such as pkgkit.

No, PackageKit should not have to worry about whether it should do a
slow or fast reboot, it just doesn't make sense to expect the
PackageKit developers or anyone else to know how to pick the right
option and why. If you go down that road, and many have, you are
guaranteed that this option either ends up in the UI or in gconf or
both.

Btw, it's pretty funny how you say in your last mail "this is not KDE"
and then continues to argue that our APIs for desktop apps (e.g. the
Restart() CK API) should have, in my view, superfluous options....

(sorry to pick on the KDE guys here)

>> > (But then again, I think the whole discussion is not too useful at
>> > all, since rebooting In my opinion should be handled only be upstart,
>> > and CK should be out of the game)
>>
>> Not sure I agree. Rebooting a box is actually much more complicated
>> than just calling reboot(8). You need to do at least the following
>> things
>>
>>  - check that the user is authorized (the needed authorization depends on
>>    whether there are more than one session)
>
> I don't have a problem whith Upstart calling into PK.

Calling into PolicyKit is the least of the problems you run into here.
Doing the ACK / Inhibit dance, which you conveniently didn't reply to,
is a lot more complicated.

     David