On Fri, 24 Sep 2004, Oliver Neukum wrote: > > Drivers will need to deal with this possibility. It also would be good if > > they could place a suspended device into an "idle" state without having to > > resume it first. I still think it's worthwhile trying to avoid resuming > > the entire system just to write the memory image to a single swap device. > > Maybe, but that's not a problem of the device core. Swsusp makes the > choice.
True. Okay, I'll ignore it. > If you are dealing with a system that has no power, everything is > hot-pluggable. The distinction is meaningless. :-) I like that way of putting it. > > Is there no way to unmount filesystems temporarily while preserving the > > memory mappings? Especially if no user processes are running at the time? > > What would the semantics of that be? Externally unmounting is equivalent > to syncing and marking the filesystem clean. Internally the state should > be the same afterwards as before. What are you trying to achieve? Well, what I was _thinking_ of achieving (in a rather inadequate faint-hearted way) was to find a way of preventing disaster when there was a mounted filesystem on media that got removed or exchanged during the suspend. But there really is no way to prevent disaster when that happens, is there? It's no different from what would happen if the user changed the media while the system was running. The important thing is for _some_ layer to recognize that something has changed, so the system doesn't go ahead blindly assuming the old media is still present. All right, the whole point is moot. But it does raise an interesting question. The USB subsystem has no way to preserve the existence of devices across power-off. If people want to keep their mounted filesystems on a USB disk during suspend-to-disk we'll need to add an appropriate facility. How should it work? What I've learned from this discussion is that there needs to be another PM device state, or really a pseudo-state. Let's call it PM_SUSPEND_IDLE. Devices in this state must not perform DMA or issue interrupt requests, but there's no requirement as to how much power they consume. Drivers _should_ be able to place devices into an idle state starting from any PM state, and they _must_ be able to place fully resumed devices into an idle state. When resuming an idle device, it's best for drivers not to assume very much about the actual state the device is in. If the driver supports multiple idle states (varying, say, according to the power level before the device was idled), then the device might be in any of them -- and not necessarily the last one the driver remembers placing it in. If the driver isn't compiled into the kernel, the device might even be in its default or virgin state. The fact that PM_SUSPEND_IDLE doesn't refer to a power level makes it difficult to fit into the scheme already established. Maybe its numerical value should be larger than any of the other states, reflecting the fact that a driver should be able to idle its device regardless of the current power level. The only legal transition out of PM_SUSPEND_IDLE to back to the full-power state. When you put everything all together, does this sound like a workable approach to power management? Alan Stern ------------------------------------------------------- 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
