Yves Martin <ymartin59@???> writes:
> En réponse à Francois-Xavier 'FiX' KOWALSKI
> <francois-xavier.kowalski@???>:
>
> > > Justement, non, l'idee de ce patch et de faire le suspend to disk
> > > dans une partition de swap sans support du BIOS. Au boot, linux
> > > detecte l'iamge et peut la redemarrer.
> >
> > Ok, le principe est interressant & permet d'ameliorer l'independance
> > vis a vis du materiel. Il y aura probablement des conflits avec LKCD
> > (qui utilise aussi la(les) zone(s) de swap comme zone de "dump").
> > lkml decidera.
> >
> > As-tu u URL decrivant cette fonction & son etat d'integration (ou
> > d'acceptation pour integration) dans le noyau?
>
> http://falcon.sch.bme.hu/~seasons/linux/swsusp.html
Merci pour le lien.
A regarder la description du patch, l'APM n'est pas utilise, ce n'est
"clean" qu'a priori: Les drivers physiques ne sont donc pas notifies
a leur reveil (resume) que le contexte materiel a pu changer, ce qui a
de bonnes chances de tout mettre "dans le vent" dans les situations
suivantes:
- peripherique deconnecte (pas de notification a remonter de l'USB),
- re-assignation d'addresse IP (quoique dhcp client a de bonnes
chances de s'en sortit quand-meme),
- j'ai un peu peur pour les connection TCP & toutes les autres
machines a etat (reseau ou non) qui dependent de notifications de la
couche physique.
Je suis donc a priori sceptique.
Ce qui serait bien avec "SysRq+s", serait:
1. ordoner un "suspend" des drivers
2. realiser le dump memoire
3. appeller l'APM pour realiser un "suspend" du H/W
4. Dodo,
5. "On"
6. La procedure de "resume" commence par recharger le dump, puis...
7. ... invoque le "resume" des drivers
Un coup d'oeil au code s'impose.
A+
--
François-Xavier 'FiX' KOWALSKI
