On Thu, 28 Oct 2004, Pavel Machek wrote: > Hi! > > > > Well, for example disk driver certainly needs interrupt controller and > > > timer devices to be working... Disk itself does not care about timer > > > devices, but driver certainly needs them. > > > > > > And it is this kind of dependencies that would make it "interesting". > > > > I'm not disputing those dependencies, but there seems to be something > > wrong. If we're writing the image with interrupts enabled, we've either > > not suspended the system devices (which means we're not saving their > > state), or we've re-enabled interrupts (which may cause some bad things if > > some system devices are disabled). If we're writing with interrupts > > disabled, then the timers and IRQ seem to be irrelevant. What am I > > missing? > > Currently, we always freeze/unfreeze the whole tree. (We write with > interrupts enabled). We do not see any of these issues. > > Someone suggested that we should only unfreeze swap device. That does > not work, see above. Why not? The suspend/resume walks of the tree don't touch system devices, which includes the set of interrupt controllers, timers, etc. It should work fine. > > How can you Save before you Stop? For each device, it needs to be in a > > consistent and quiescent state before you save its state. > > For example ipw2100 would like to have pre-stop phase, where it could > read firmware from filesystem and store it to RAM. I thought your > "Save" refers to this one. I was speaking only of the average case - saving device register state. Userspace interaction is an entirely different topic. Pat
