From: "Raymano Garibaldi" <raymano@faunos.com>
To: "Alan Stern" <stern@rowland.harvard.edu>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"Denys Vlasenko" <vda.linux@googlemail.com>,
"Kernel development list" <linux-kernel@vger.kernel.org>,
"USB development list" <linux-usb-devel@lists.sourceforge.net>
Subject: Re: [linux-usb-devel] [BUG] USB_PERSIST
Date: Mon, 26 Nov 2007 11:43:50 -0700 [thread overview]
Message-ID: <1618816c0711261043nfa61e63m59d242fbbd6a8d6@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0711260958001.3987-100000@iolanthe.rowland.org>
Thanks for responding Alan.
On 11/26/07, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Sun, 25 Nov 2007, Raymano Garibaldi wrote:
>
> > The device which has the root fs is a READ-ONLY device. There is no
> > way for it to change between getting detached and reattached to the
> > computer which is suspended.
>
> You might think so at first. But suppose another device of the same
> type got plugged in instead -- with different data stored on it. That
> would be just as bad.
>
This is possible. However I believe giving an option to the user to
allow this behavior is important. It's about choice.
> > I understand that this is currently considered a feature but I am
> > arguing here that there should also be another feature that allows
> > this to work under suspend to ram the same as it does with suspend to
> > disk (hibernation).
> ...
> > This scenario is not currently possible with the any kernel after
> > 2.6.22. It is a very important missing feature.
>
> This has nothing to do with USB particularly; it applies to all forms
> of hot-pluggable or removable storage. Even floppy disks.
>
True.
> > And yes. This feature does work under the 2.6.21 kernel, exactly
> > because the kernel did not have the USB suspend and persist feature
> > available.
>
> Wait a minute. You're saying that USB Persist worked under 2.6.21
> because it wasn't available? That makes no sense. Besides, if you
> don't like USB Persist under 2.6.23, you can always eliminate it by
> turning off CONFIG_USB_PERSIST.
>
I have tried this. Simply turning off CONFIG_USB_PERSIST doesn't work.
In this case the USB drive file system is unmounted on resume, even if
the drive remained plugged in during suspend.
> > Under the 2.6.21 kernel, during suspend, the kernel is
> > totally unaware of what is happening to the USB device so nothing
> > happens when the USB device is detached and reattached while the
> > computer is suspended, hence making the described scenario above
> > possible. I currently, and very frequently, use this feature on my
> > live USB distro, FaunOS which uses kernel 2.6.21.
>
> It may be the case that _your_ particular computer wasn't aware of
> unplug or replug events during suspend, but if so then it was a bug and
> it isn't true in general. The fact that your computer is now aware of
> these things proves this.
>
I have tried this on many different computers. Also our distro users
have successfully tried this throughout the world. Whether it was a
bug or not, the desired behavior existed in kernel 2.6.21.
> In short, you aren't reporting a bug -- you're asking for a new feature
> to be added.
>
> From the point of view of the kernel, being suspended is in some
> respects like remaining awake. Hotplug events are detected in either
> case. Would you also want the ability to unplug and replug your root
> fs while the computer was running? Would it make sense to add such an
> ability?
>
Yes. I believe because of the advances in solid state drive
technology, especially detachable ones like USB flash drives, the
ability to unplug and replug a live root fs is becoming an important
feature.
> There was a time during the 2.4 kernel series when usb-storage would
> try to keep track of devices after they had been unplugged and
> recognize them when they were re-attached. Linus himself said it was
> a bad idea and consequently it was removed. Now you're saying you want
> it back. I think you'll have to convince Linus before anyone else will
> pay attention. It's worth a try -- he might think your airport
> scenario is common enough to be worth supporting.
>
> Alan Stern
>
>
Thanks again Alan. I will post a feature request.
Raymano G.
next prev parent reply other threads:[~2007-11-26 18:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-19 4:14 Raymano Garibaldi
2007-11-19 4:37 ` Denys Vlasenko
2007-11-19 6:18 ` Raymano Garibaldi
2007-11-21 0:04 ` Raymano Garibaldi
2007-11-25 6:39 ` Andrew Morton
2007-11-25 16:06 ` [linux-usb-devel] " Alan Stern
2007-11-26 5:17 ` Raymano Garibaldi
2007-11-26 15:16 ` Alan Stern
2007-11-26 18:43 ` Raymano Garibaldi [this message]
2007-11-26 22:17 ` Alan Stern
2007-11-28 6:02 ` Raymano Garibaldi
2007-11-28 22:14 ` Alan Stern
2007-11-29 11:53 ` Raymano Garibaldi
2007-11-29 16:08 ` Alan Stern
2007-11-29 19:01 ` Mark Lord
2007-11-29 19:07 ` Alan Stern
2007-11-30 4:37 ` Raymano Garibaldi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1618816c0711261043nfa61e63m59d242fbbd6a8d6@mail.gmail.com \
--to=raymano@faunos.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=stern@rowland.harvard.edu \
--cc=vda.linux@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®