[lkml]   [2004]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Swsusp-devel] Re: swsusp problems [was Re: Your opinion on the merge?]
May I request that you leave the authors headers intact when quoting. Thank you.

On Wed, 24 Mar 2004 11:17:04 +0100, Pavel Machek <> wrote:

>> >>So why aren't you arguing against bootsplash too? That definitely
>> >>obscures such an error :> Of course we could argue that such an error
>> >>shouldn't happen and/or will be obvious via other means (assuming it
>> >>indicates hardware failure).
>> >
>> >Of course I *am* against bootsplash. Unfortunately I've probably lost
>> >that war already. But at least it is not in -linus tree (and that's
>> >what I use anyway) => I gave up with bootsplash-equivalents, as long
>> >as they don't come to linus.
>> >
>> >[And I believe Linus would shoot down bootsplash-like code, anyway.]

Why? Joe consumer wants it.

As to the ever growing size of the kernel, there could be a official addons/tools
tree with non-core functions maintained by a seperate maintainer. Things like
debuggers, profiling or (swsusp) debug support could go there as well...

>> Solution: Auto switch to non-swsusp VT on error showing the error message.
> Hmm, at that point you loose context, like now you know what error
> happened, but do not know at which phase of suspend. That's pretty bad
> too.

Right, Good idea! Just print always "ugly" swsusp context on a text VT - plus any
error messages - and switch over to this VT in printk when not in interrupt
context. 10 lines of code or so in printk ;)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:01    [W:0.087 / U:0.844 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site