mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.

  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®