The problem with VM is that you don't really have one swap device.
You can have swap on files from several devices, you can have mmap'ed
files from any mounted filesystem on any block device, you can have
That's why we must completely separate allocation from blocking of
activity. If we do so, we don't need to care about any ordering rule
between drivers (at least not because of this problem, other issues
may require ordering rules, but it's an arch matter).
>> The actual state save can be in step 2 or 3, we don't really care,
>> it depends mostly on what is more convenient for the driver writer.
>For most devices, it seems it could happen in the first, as well. They
>should be fine with stopping I/O requests early on. It's only special
>cases like swap and maybe one or two others that need an extra step,
Well, you may think it's ok to do it, let's say, for a serial port, in
step 1. But... what about NFS over PPP over that serial port ? :)
If a device don't need to allocate memory and can do the save_state
and shutdown in one step, then it only need to respond to step 2. It
will skip step 1 and step 3.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/