From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pavel Machek <pavel@suse.cz>, Andreas Mohr <andi@lisas.de>,
Sriram V <vshrirama@gmail.com>,
Pierre Ossman <drzeus-list@drzeus.cx>,
linux-kernel@vger.kernel.org
Subject: Re: Power Management with rootfs on SDMMC.
Date: Sun, 4 Jan 2009 12:04:15 +0000 [thread overview]
Message-ID: <20090104120415.33e32c6b@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <alpine.LFD.2.00.0901031854320.3179@localhost.localdomain>
> > I don't believe "auto-destroy my music collection" is a sane default...
>
> You are missing the point.
Nope.
> You have one totally made-up example of something that may happen as a
> result of a default I didn't even advocate (but you didn't read my email).
Actually I went and verified the behaviour of the iRiver iHP20.
> There really was nothing theoretical in my issue. On a certain class of
> hardware, you absolutely _have_ to make your /home or / partition be
> behind a USB thing, because nothing else has enough space on it.
Yes clearly.
> And your made-up example wouldn't even trigger if we just made a per-mount
What made up example ?
> decision to mark devices persistent.
The distribution question is 'how do you make that decision reliably and
correctly ?'. That is closely followed by 'what state should it end up in
if the relevant scripts don't run for some reason ?' - which is clearly
"not persistent" for safety reasons.
> So why are you arguing?
I'm not aware I was. I was simply pointing out that
- the general distribution default cannot be one that harms user data on
music players
- that you can fix it more elegantly by quiescing and validating file
systems across a suspend/resume
neither of which appears to disagree with the point that you want USB (or
increasingly SD card) to be able to autoresume when it holds file
systems. It does however make clear which way around any kernel default
should be.
Alan
next prev parent reply other threads:[~2009-01-04 12:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-02 6:35 Sriram V
2009-01-02 10:21 ` Andreas Mohr
2009-01-02 11:21 ` Pierre Ossman
2009-01-02 12:21 ` Andreas Mohr
2009-01-02 17:24 ` Pavel Machek
2009-01-03 20:23 ` Linus Torvalds
2009-01-03 20:43 ` Pavel Machek
2009-01-03 20:45 ` Alan Cox
2009-01-03 21:16 ` Linus Torvalds
2009-01-03 23:10 ` Alan Cox
2009-01-04 2:59 ` Linus Torvalds
2009-01-04 12:04 ` Alan Cox [this message]
2009-01-04 17:53 ` Linus Torvalds
2009-03-29 16:26 ` Andreas Mohr
2009-04-05 18:45 ` Pierre Ossman
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=20090104120415.33e32c6b@lxorguk.ukuu.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=andi@lisas.de \
--cc=drzeus-list@drzeus.cx \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@suse.cz \
--cc=torvalds@linux-foundation.org \
--cc=vshrirama@gmail.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®