From: Linus Torvalds <torvalds@linux-foundation.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
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 09:53:08 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.2.00.0901040946280.3179@localhost.localdomain> (raw)
In-Reply-To: <20090104120415.33e32c6b@lxorguk.ukuu.org.uk>
On Sun, 4 Jan 2009, Alan Cox wrote:
>
> 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.
No.
You clearly haven't even read my emails. I quote:
And yes, the "sane defaults" may well be that FATFS does _not_ make the
media be persistent.
however, the sane default remains that things like / and /home _should_ be
marked persistent.
> I was simply pointing out that
>
> - the general distribution default cannot be one that harms user data on
> music players
No you were not. You were repeatign that mantra as if it was relevant,
when it isn't.
> - that you can fix it more elegantly by quiescing and validating file
> systems across a suspend/resume
Send me a patch.
Hint: you can't sanely even validate it without teaching the USB layer
_not_ to disconnect and re-connect the damn thing on resume (ie set the
"persistent" flag), because that can easily cause totally unrelated
changes to cause the device to be re-enumerated. How do you even find it?
In other words, you're wrong.
The only sane thing to do is what I already outlined: teach the
mount-points (and yes, on a per-mount-point basis) to mark the devices
persistent, and make the device drivers honor that.
Then, in _addition_, you can - once the device stays around - you can also
add a filesystem callback for suspend/resume, and make the filesystem try
to do extra sanity checking.
But quite frankly, that's very much the secondary stage, since it won't
matter in any sane real situation (ie once you've simply said that "we
don't cae about FAT being persistent"). And it's a secondary stage also
simply because it needs to happen _after_ you've already made the ones you
care about persistent, since it simply won't work otherwise.
Linus
next prev parent reply other threads:[~2009-01-04 17:53 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
2009-01-04 17:53 ` Linus Torvalds [this message]
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=alpine.LFD.2.00.0901040946280.3179@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=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=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®