Re: 2.6.9-rc2-mm1 swsusp bug report.

[Jan Rychter]

>>>>> "Pavel" == Pavel Machek <pavel@xxxxxx> 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/