Hi. On Wednesday 26 April 2006 04:56, Rafael J. Wysocki wrote: > You're saying that (9) is wrong, so could you please suggest what to do > instead of it?
'scuse me for butting in, but here's my suggested modified version: > Well, suppose we have a modular driver that's not loaded before resume. > Then it goes like that (approximately): > (1) We activate swsusp which calls .suspend() for all devices including our > driver (this is a real suspend). > (2) swsusp snapshots the system and creates the image. > (3) swsusp calls .resume() for all devices in order to be able to save the > image (.resume() for our driver is also called which is OK). > (4) swsusp turns off the system. > (5) (some time later) We start a new kernel and tell it to resume. > (6) It activates swsusp which reads the image. > (7) (without your change) swsusp calls .suspend() for all device drivers > that are present at that time, but our driver is not there, so its > .suspend() _won't_ be called. [Of course with your change .suspend() won't > be called for any driver.] We also make a list that is safely available after the atomic restore of drivers that have had .suspend methods called. > (8) swsusp restores the image. (9) suspend to disk calls .resume() for each device that is found in the list generated above, thereby excluding our problem driver. Drivers which are present but not in the list above (such as the problem driver) have a different routine called, perhaps the normal initialisation one? Regards, Nigel -- See our web page for Howtos, FAQs, the Wiki and mailing list info. http://www.suspend2.net IRC: #suspend2 on Freenode
pgph54I2MdKN4.pgp
Description: PGP signature
