Russell Coker wrote: > On Tue, 16 Mar 2010, Michael Tokarev <m...@tls.msk.ru> wrote: >>> When the path specified by -mem-path isn't writable the error message >>> "mkstemp: Permission denied" is displayed on stderr - which means that it >>> can't be seen until after the kvm session is ended when using the -curses >>> option. >> Russell, it's the same thing as #574063 again. If you redirected stderr >> to /dev/null, please don't complain that you see no useful error message. > > But when an application redirects it's own output to /dev/null it's something > that needs to be fixed - I've filed Debian bug reports about that before.
In this case the application does not do any redirections, and the output is actually visible, but only after guest output gets erased. >> With -curses the current terminal is used for entirely different purpose >> (guest output), and if you at the same time want to see stderr, redirect >> it to a file or a pipe, or use some management software. > > Or kvm could use syslog or some other mechanism for logging such things. Where the error message will not be noticed either. With current form it at least has a chance to be noticed after the guest exits. In short, I disagree with your points, and think - based on my own experience - that currently kvm does the best (modulo the error message _text_). I fully agree about the usefulness of the particular error message, and I already sent a patch to upstream fixing this (trivial one-liner). >> Generally, and it applies to #574063 too, kvm lacks control over "failure >> reaction": here when it is unable to allocate hugepages, and in #574063, >> when it can't initialize /dev/kvm, and in some other cases, it currently >> continues, but sometimes it is useful to stop here with error. There is >> no way currently to tell kvm to turn such "warning" messages into fatal >> errors. > > The lack of a way to turn warnings into fatal errors is a bug. Think > of -Werror for C compilation. -Werror is something different really. For kvm we're talking about optional features, and how to react to them lacking - either continue with a warning or stop - depends on the point of view. Some will say current ways is good, others says it is not, and both has their points. For now it is upstream decision, and I think the best option - if you want the discussion about errors-vs-warnings to continue with some productivity - is to move it to upstream mailinglist. Ditto about error reporting in case of -curses. Note that the same theme pops up in context of -daemon option, where kvm may actually close stderr as you mentioned above. I'm relatively new to Debian still (speaking of package maintenance anyway) and don't know how a maintainer usually should treat ideas and suggestions about a package when said ideas are clearly should be at least discussed with upstream, -- the actual author(s) of the piece of software in question. But in any way, I personally do not see a problem here, from "error reporting" perspective (however, the -daemon case needs to be checked). About treating warnings as errors, -- this is actually useful, at least for #574063, -- so my current plan is to left both bugs open for now, and close #574063 when kvm will be able to stop if no kvm extensions are present and close this #574073 after changing text of the error message to something more meaningful. >> By the way, 0-72 version as shipped in Lenny is a joke nowadays. It is >> not a bad development snapshot, but it is still a development snapshot, >> just like all other kvm-NN "releases" were. If you intend to play or >> even use kvm, grab it from backports (it's called qemu-kvm there) - this >> version is a bit closer to released software than kvm-72 in lenny. I for >> one will not try to support it in any way, unless the same problem exists >> in qemu-kvm-0.12. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574060 > > My first attempt at reporting such bugs involved reproducing some of them on > Unstable, but unfortunately they got lost (see the above reportbug bug). Yeah, it's PITA when debuggers needs to be debugged before being useful... But I were talking about bpo really, not about unstable. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
