Re: Flames over -- Re: Which is simpler?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Feb 13, 2006, at 23:28, Alan Stern wrote:
On Mon, 13 Feb 2006, Kyle Moffett wrote:
A good set of suspend scripts should handle the hardware-suspend with no extra work because hardware supporting hardware-suspend basically inevitably supports USB low-power-mode,

Unfortunately a lot of hardware doesn't support USB low-power mode. I guess you'd say therefore it doesn't really support hardware-suspend. This may be so, but it's small comfort to the owners of those systems.

I have to admit, although technically Phillip's argument is wrong, from a usability standpoint it is right. Windows allows users to disconnect and reconnect USB storage devices while the system is hibernating, with no apparent ill effects -- although I've never tried to unplug one device and then plug in a different one on the same port while the computer was asleep. I don't know to what extent Windows checks descriptors/serial numbers/disk labels/ whatever when it wakes up.

For the software-suspend/no-low-power-mode case, I see a couple of practical and spec-conforming options:

1) The kernel should notice that it has a filesystem mounted from a hotpluggable block device and abort the suspend process. This isn't terribly user friendly, but is guaranteed to prevent data loss, and a good set of suspend scripts could notice the reason for failure and report it to the user (optionally unmounting the filesystems automatically and retrying).

2) The kernel should notice that it has a filesystem mounted from a hotpluggable block device and forcibly unmount said filesystem. This is also not user-friendly, and has the disadvantage of not being easily userspace-controllable.

3) The kernel should notice that it has a filesystem mounted from a hotpluggable block device and forcibly disconnect the mount. Beforehand, uswsusp would have saved information about all mounted blockdevs into the suspend file/disk. When resuming, early userspace would reread that information and attempt to relocate the block devices from userspace, using any tools available to it at the time (including a bunch of fs-probing tools and such). After it's scanned devices and found any that it could reliably get, it would pass that information to the kernel being resumed which would use it to reattach filesystems to disks. This is a lot more complicated, but more user friendly. It has the downside of making the kernel do a lot of extra unreliable work looking up paths and files again, but it might work in a good percentage of the cases. I doubt the advantages of this one over (1) or (2) are worth the added complexity, though.

Cheers,
Kyle Moffett

--
Simple things should be simple and complex things should be possible
  -- Alan Kay



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux