Michael Schuerig wrote: > Ich habe vorhin nach langer Zeit mal wieder einen Versuch unternommen, > mein Notebook (Dell D820) schlafen zu legen, sowohl ins RAM als auch > auf die Platte. Zu meiner Erleichterung und Verblüffung hat es einfach > so funktioniert, das war beim letzten Versuch noch anders. > > Eine knappe Stunde habe ich dann damit verbracht, herauszufinden, was > und wie dabei überhaupt zusammen spielt. Ich habe in > KPowersave "Suspend to Disk/RAM" aufgerufen, was wiederum nur als GUI > für powersaved dient. Dort wird offenbar ein D-Bus-Event ausgelöst, der > wiederum an pm-hibernate/-suspend(-hybrid) aus dem pm-utils delegiert > wird, die schliesslich s2ram oder s2disk aus uswsusp aufrufen. Fast richtig, aber nicht ganz. Alte kpowersave versionen (< 0.7) haben powersaved als backend verwendet, und powersaved (< 0.15) hat ein eigenes suspend framework mitgebracht. Mit kpowersave 0.7.x und powersaved 0.15.x wurde das (Gott sei Dank) konsolidiert. Im wesentlichen, läuft alles über HAL/D-Bus mit pm-utils als backend. Der Ablauf ist im wesentlichen folgender: hald wird gestartet und ruft pm-is-supported auf (mit den verschiedenen parametern --suspend, --hibernate --suspend-hybrid). Je nachdem, was pm-is-supported zurückliefert, werden in hal die folgenden properties gesetzt: # lshal | grep power_management.can_* power_management.can_hibernate = true (bool) power_management.can_suspend = true (bool) power_management.can_suspend_hybrid = true (bool) Wenn du jetzt in der Desktop-Session kpowersave (oder gnome-power-manager) startest, verbindet sich es sich über D-Bus zu HAL. Die entsprechenden D-Bus zugriffsrechte dafür müssen vorhanden sein (siehe /etc/dbus-1/system.d/hal.conf), bieten die entsprechenden, unterstützten suspend or hibernate optionen in der GUI an und registrieren sich bei HAL für events, wie lid-close oder battery charge. kpowersave und gnome-power-manager werden oft als policy agents beschrieben. Im Prinzip wird die komplette Funktionalität bereitgestellt (über HAL), und die policy-agents legen nur noch fest, was bei welchem Event passieren soll und rufen dann entsprechende HAL Methoden auf. Möchtest du nun ein Suspend (oder Hibernate) durchführen (entweder weil du es explizit angeklickt hast oder der Deckel geschlossen wurde), so wird die HAL Methode org.freedesktop.Hal.SystemPowerManagement.Suspend() (bzw. Hibernate()) aufgerufen (die Kommunikation läuft über D-Bus) Installier einfach mal d-feet und schau dir die D-Bus Methoden an, die HAL unter /org/freedesktop/Hal/devices/computer anbietet. Intern macht dann HAL nichts anderes als das shell script /usr/lib/hal/scripts/hal-system-power-suspend aufzurufen. Dass wiederum ruft je nach plattform (ich nehme mal an es ist linux bei dir und nicht *BSD) /usr/lib/hal/scripts/linux/hal-system-power-suspend-linux auf. Da viele Laptops bestimmte workarounds, auch quirks genannt, brauchen, und diese Information in der hal datenbank stecken: # lshal | grep power_management.quirk wird nun die korrekte kommandozeile für pm-utils zusammengebaut und pm-suspend mit den korrekten parametern aufgerufen. pm-utils ist ein framework, dass sich nun um das eigentliche suspend/hibernate kümmert. Es gibt, was Hibernate (oder suspend-to-disk) angeht, im wesentlichen 3 implementationen: - in kernel suspend to disk - userspace software suspend to disk (über uswsusp) - Suspend2 oder TuxOnIce Bei Suspend (oder suspend-to-ram) gibt es eigentlich nur die eine In-Kernel Implementation, und s2ram ist im wesentlichen nur ein komfortableres # echo "mem" > /sys/power/state Ist das uswsusp Paket installiert, wird automatisch dieser Modus verwendet. Fallback ist kernel (siehe auch man pm-suspend: SLEEP_MODULE) pm-utils macht jetzt dinge, wie module entladen, dienste stoppen, graphikkarten context sichern und wiederherstellen und das eigentliche Schlafenlegen. Zusammengefasst läuft es also im Wesentlichen so ab: (kpowersave|g-p-m) ---> Suspend()/Hibernate() D-Bus call ---> HAL ---> quirks aus Datenbank holen und das hal-system-power-(suspend|hibernate) shell skript aufrufen ---> Kommandozeile für pm-(suspend|hibernate) zusammenbauen und pm-(suspend|hibernate) aufrufen ---> pm-utils führt die hooks in /usr/lib/pm-utils/sleep.d aus, stellt fest welches backend verwendet wird (kernel|uswsusp|tuxonice) und ruft dessen Methode do_suspend() bzw do_hibernate() auf. Zugegebenermassen sind bei diesem Vorgang etliche Komponenten beteiligt. Dass tolle jedoch ist, dass es völlig Plattform und Desktop unabhängig ist und es eine zentrale quirks Datenbank (in HAL) gibt. Im wesentlichen verwenden alle (wichtigen) Distributionen diesen Stack heutzutage. Vor nicht allzu langer Zeit gab es noch zig unterschiedliche power management script suites und jede Distro hat ihr eigenes Süppchen gekocht. Gruss, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Attachment:
signature.asc
Description: OpenPGP digital signature