lkml.org 
[lkml]   [2006]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Flames over -- Re: Which is simpler?
Date
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-02-14 06:15    [W:0.110 / U:1.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site