Re: [Swsusp-devel] Re: swsusp problems [was Re: Your opinion on the merge?]

[Michael Frank]

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 <pavel@xxxxxx> 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 ;)

Michael





-
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/