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

[Pavel Machek]

Hi!

> > > > Now I have _proof_ that eye-candy is harmfull. What is see on screen is:
> > > 
> > > No, that's not proof; just a bug in the code. It's not using the right
> > > code to display the error message. I'll fix it asap.
> > 
> > :-)
> > 
> > I'd really like eye-candy code to be gone. Its long, and its not worth
> > the trouble.
> 
> Pejorative comments aside Pavel, it is valued feedback for end-user
> re-assurance. It has also helped swsusp2 get streets ahead of the other
> implementations by aiding end-user feedback on a wide range of hardware,
> Which would appear to be well worth it? If it's not broke (and is
> valuble) why rip it out?

Its 1000 lines. If it is not broken now, it will be broken in 2.8, and
because it is in mainline, it will be up to linus to fix it.

Oh and it is enough confusing that it confuses me. Some messages end
in dmesg, some do not. User feedback can be done with much less code,
and also slightly less confusing for the user, see swsusp1. [We have
to switch to another console, anyway; and printing dots is easy.]

Okay, we should probably make suspend more quiet, I can see users
badly confused by those hdX: spinning down (etc) messages.

Also, in your model, where do messages printk()-ed from drivers during
suspend/resume end up? Corrupting screen? Lost from sight and only
accessible from dmesg? I believe driver messages *are* important, and
do not see how they could coexist with eye-candy.

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
-
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/