Messages in this thread | | | Date | Thu, 25 Mar 2004 06:46:12 +0800 | From | "Michael Frank" <> | Subject | Re: [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 <pavel@ucw.cz> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |