> > > However when the restored image begins executing, drivers may expect the
> > > devices to be in the same state as before the image was created. This
> > > argues that idle devices must be in a known state, which is presumably one
> > > of minimum power usage. That would be okay, except:
> >
> > Presumably the state would be the state at power up.
>
> What if, as you suggest, there are other hosts on the bus using the
> device? Aren't they liable to alter the device from its power-up state?
The same problem is facing probe(). The driver must be able to deal with it.
> > > I don't know how late in the boot process the memory image is restored.
> >
> > At the very end.
>
> Before or after the init process begins running in userspace?
Before. Just before the __init sections are dumped.
> > > But it's safe to guess that all the drivers may not have been loaded yet
> >
> > AFAICT the image includes all modules.
>
> No -- I'm not talking about the memory image; I'm talking about the bootup
> kernel. There may be modules stored in the memory image that aren't yet
> loaded into the bootup kernel when the resume-from-disk operation begins.
Yes. They will get devices in their virgin state. Statically compiled drivers
will have initialised their devices. The problem is solveable with
#ifdef MODULE
[..]
> > A problem for higher layers. Higher layers should checksum media.
>
> I agree, but they don't always do it and it's not always practical.
If upper layers can't find out, neither can we.
> > > To be safe, the kernel must assume that all such devices have gone away
> > > when the image starts executing. Mounted filesystems would be in trouble.
> > > Ideally _all_ non-virtual filesystems should be unmounted during the
> > > suspend-to-disk, before the image is prepared. Restoring the device
> >
> > That negates the purpose of suspension. If you unmount everything
> > you are doing a conventional power cycle.
>
> Not true. User programs would remain running across a suspend.
Then the filesystems they are mmapped from must remain mounted.
> > At least that root fs must
> > remain mounted. But if something must stay mounted, everything can
> > remained mounted.
>
> Why must the root fs remain mounted? Why can't the kernel remount it
> before unfreezing the processes?
A forced unmount would break the connection between memory mappings
and filesystems. You may call sync, but user space can do so before
requesting a suspension.
> Anyway, I didn't say everything _had_ to be unmounted, just that it would
> be good to do so. The only dangerous devices are ones with hot-pluggable
> transports or removable media.
>
> > > Assuming all devices are suspended, it is really necessary to resume
> > > everything in order to write the memory image to a partition? Or would it
> >
> > Depends on permissible swap partitions. If i-scsi is allowed all network
> > interfaces must be up. Or rather, there's no way to calculate which
> > would have to be up.
>
> At least, no easy way. What device does the i-scsi driver use as the
> parent for its SCSI host?
I have no idea.
> > > suffice to resume just the swap device and its ancestors in the power
> > > tree? Come to think of it, is a tree really the right sort of data
> > > structure to express the power dependencies in the system? Isn't it
> > > possible to have devices that won't work right unless _several_ other
> > > devices (not all of them its ancestors) are powered on?
> >
> > Nevertheless the ordering constraints must be met requiring a tree.
>
> It seems to me you've just indicated a case (i-scsi) where a tree is
> insufficient, because the network adapters that must be turned on before
> using an i-scsi host aren't among the ancestors of that host. The
> ordering constraints are _more_ strict than can be expressed using a tree.
Please don't ask me to come up with a better structure.
Regards
Oliver
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
