mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jan Rychter <jan@rychter.com>
To: linux-kernel@vger.kernel.org
Subject: Re: 2.6.9-rc2-mm1 swsusp bug report.
Date: Mon, 11 Oct 2004 23:53:29 +0900	[thread overview]
Message-ID: <m2hdp1gvbq.fsf@tnuctip.rychter.com> (raw)
In-Reply-To: <20041011133234.GA16217@atrey.karlin.mff.cuni.cz>

>>>>> "Pavel" == Pavel Machek <pavel@ucw.cz> writes:
 Pavel> Hi!  You do not know how much you should preallocate, because it
 Pavel> depends on ammount of memory used. You could preallocate maximum
 Pavel> possible ammount...
 >>
 Pavel> OTOH this is first report of this failure. If it fails once in a
 Pavel> blue moon, it is probably better to let it fail than waste
 Pavel> memory.
 >>
 >> This is *exactly* why I choose to use swsusp2. There is a marked
 >> difference in the maintainer's approach to these kinds of problems.

 Pavel> Okay, and do you have something to say or do you want to start
 Pavel> flamewar? That is also why swsusp2 is 10 times code size of
 Pavel> swsusp...

Sure, flame me if you think this is the right thing to do. But I will
continue to pitch in with a users' opinion sometimes, because I really
believe it is important.

It is easy to lose sight of the user perspective on these things if all
you deal with is kernel development. You probably reboot your machine
dozens of times a day anyway. However, for some users crashes and
reboots are *very* expensive. These people (myself included) consider
sprinkling the code with panics, crashing and failing an unacceptable
thing to do.

I also believe your reply shows how important it is for me to actually
write things like these from time to time (even risking getting
flamed). As a user I don't care whatsoever what the code size
is. Actually, I don't care that much about its performance, either. What
I do care about is that my operating system doesn't crash from under me,
doesn't lose my data, and doesn't fail on me with suspending when I
really need it to suspend now. Give me a userspace USB implementation
that works 10x slower and is 10x larger but doesn't crash my machine and
I'll take it any day.

--J.


  reply	other threads:[~2004-10-11 14:57 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2HO0C-4xh-29@gated-at.bofh.it>
     [not found] ` <2I5b2-88s-15@gated-at.bofh.it>
     [not found]   ` <2I5E5-6h-19@gated-at.bofh.it>
     [not found]     ` <2I7Zd-1TK-11@gated-at.bofh.it>
2004-09-25  1:05       ` Pascal Schmidt
2004-09-25 10:16         ` Pavel Machek
2004-10-10 18:17           ` Jan Rychter
2004-10-11 13:32             ` Pavel Machek
2004-10-11 14:53               ` Jan Rychter [this message]
2004-10-17 19:10                 ` Pavel Machek
2004-10-17 21:40                   ` Nigel Cunningham
2004-10-11  9:56           ` Stefan Seyfried
2004-10-11 14:59             ` Pavel Machek
2004-10-11 17:18               ` Stefan Seyfried
2004-10-11 19:58                 ` Rafael J. Wysocki
2004-10-12  8:55                   ` Pavel Machek
2004-10-13 17:29                     ` Rafael J. Wysocki
2004-10-14 21:47                       ` swsusp: 8-order allocation failure on demand (was: Re: 2.6.9-rc2-mm1 swsusp bug report.) Rafael J. Wysocki
2004-10-14 21:54                         ` swsusp: 8-order allocation failure on demand (update) Rafael J. Wysocki
2004-10-16 16:43                           ` Pavel Machek
2004-10-16 19:31                             ` Rafael J. Wysocki
2004-10-16 20:40                               ` Pavel Machek
2004-10-16 21:05                                 ` Rafael J. Wysocki
2004-10-16 21:25                                   ` Pavel Machek
2004-09-24  2:19 2.6.9-rc2-mm1 swsusp bug report Kevin Fenzi
2004-09-24 14:37 ` Pavel Machek
2004-09-24 21:09   ` Kevin Fenzi
2004-09-24 23:40     ` Nigel Cunningham
2004-09-25  1:45       ` Kevin Fenzi
2004-09-25 11:53         ` Nigel Cunningham
2004-09-25 12:22           ` Nick Piggin
2004-09-25 12:56             ` William Lee Irwin III
2004-09-25 13:21               ` Nigel Cunningham
2004-09-25 12:56             ` Nigel Cunningham
2004-09-25 13:38               ` Nick Piggin
2004-09-25 13:03             ` Nigel Cunningham
2004-09-25 15:45             ` Pavel Machek
2004-09-25 22:03               ` Nigel Cunningham
2004-09-26 10:04                 ` Pavel Machek
2004-09-26 21:59                   ` Nigel Cunningham
2004-09-26 22:43                     ` Pavel Machek
2004-09-27 10:12                       ` Nigel Cunningham
2004-09-26 16:18           ` Marcelo Tosatti
2004-09-26 18:39             ` Pavel Machek
2004-09-25 10:15     ` Pavel Machek

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=m2hdp1gvbq.fsf@tnuctip.rychter.com \
    --to=jan@rychter.com \
    --cc=linux-kernel@vger.kernel.org \
    /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®