[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.98.0704251621530.9964@woody.linux-foundation.org>
Date: Wed, 25 Apr 2007 16:29:34 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Pavel Machek <pavel@....cz>
cc: Nigel Cunningham <nigel@...el.suspend2.net>,
Kenneth Crudup <kenny@...ix.com>,
Nick Piggin <npiggin@...e.de>, Mike Galbraith <efault@....de>,
linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
Con Kolivas <kernel@...ivas.org>,
suspend2-devel@...ts.suspend2.net, Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
Arjan van de Ven <arjan@...radead.org>
Subject: Re: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2:
hang in atomic copy)
On Thu, 26 Apr 2007, Pavel Machek wrote:
>
> Current design is:
Broken. Yes. I've tried to tell you.
> Twice. Once during snapshot (then we spin it up when the snapshot is
> done), and once during shutdown.
And nobody can possibly say that is "sane". But it's a direct result of
the incorrect thinking that "suspend()" and "snapshot()" have anything
what-so-ever to do with each other.
> Yep, we optimize away spindown, because it takes too long, so SCSI
> disks are actually very bad example.
No. SCSI disks are a *good* example. It's an example of how you
(incorrectly) call the same function for two totally different things, and
then that function is smart enough that it *understands* that they are
totally different.
But the *confusion* remains. It remains in your head, and you've poisoned
people like Alan too, that usually are not confused. And THAT is the main
problem (although there are also indirect problems like "fixing one may
break the other", but I actually think that the fundamental problem is the
confusion it creates, which in turn causes bugs to happen because people
are confused and think that they should do the same thing for suspend and
for snapshot).
> No, I'd like you to understand that we actually CAN tell the disks to
> spin down, because we'll call resume and spin them back again before
> writing the image. We used to do it. We still can do it, but it is
> slow.
>
> Yes, it is quite confusing.
It's worse than just confusing, it's *idiotic*.
It _can_ work in practice, but
- we have pretty damn solid evidence that it doesn't work all that often
in practice
- the fact that something *can* be done the stupid way is in no way an
argument that it *should* be done the stupid way.
I claim that the current STD is *stupid*. Yes, it can work. But that
doesn't make it less stupid.
What's your argument? Your argument seems to be that it's not stupid,
because it can work. Can't you see that that simply isn't an argument at
all? "stupid and wrong" doesn't mean "cannot work in theory". But it
*does* mean that people get confused, and it *does* mean that there are
likely more bugs, because confused people do not tend to write very good
code.
I'm not claiming that the current code cannot work. It clearly *does*
work for a lot of people. But I'm claiming that it's STUPID.
So don't argue that "it works". Windows works, kind of. That doesn't make
it less stupid and badly designed!
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists