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

From: Michael Frank
Date: Wed Mar 24 2004 - 19:21:46 EST

On Thu, 25 Mar 2004 00:23:38 +0100, Pavel Machek <pavel@xxxxxx> wrote:

On Ät 25-03-04 06:46:12, Michael Frank wrote:
May I request that you leave the authors headers intact when quoting. Thank

As you wish.

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
tree with non-core functions maintained by a seperate maintainer. Things
debuggers, profiling or (swsusp) debug support could go there as

Yes, having -nice patch with bootsplashes, translated kernel messages,
and swsusp eye-candy would work for me.

If a -nice _tree_ is useful, your guys just have to launch it. Gosh this could reduce
arguments about what goes into the kernel and save Linus and Andrew lots of work.

Feel free to maintain it.

Busy enough with testing, actually far too busy for being on a volunteer basis ;)

I am sure that better qualified and properly supported/sponsored individuals
will queue up as long as it is an _official_ -nice tree with the good purpose
of centralizing useful non-core functions :)

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

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 ;)

You see, 10 lines in printk is probably good enough reason not to
include that patch in kernel, because its "too ugly".

Pretty does not count above, Ugly does not count here, Functionality always does.
Besides that patch might be in the -nice tree.

Plus it does not work if printk _was_ from interrupt context.

Kernel knows when in interrupt context and can defer switching.

swsusp really should not have patch any code outside kernel/power.

Which is extremely ideal, but one thing at the time...

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