qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] stop using stdio for monitor/serial/etc with


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH v2] stop using stdio for monitor/serial/etc with -daemonize
Date: Sat, 27 Oct 2012 12:48:28 +0000

On Sat, Oct 27, 2012 at 12:15 PM, Michael Tokarev <address@hidden> wrote:
> On 27.10.2012 15:33, Peter Maydell wrote:
>> On 27 October 2012 12:23, Michael Tokarev <address@hidden> wrote:
>>>
>>> I still don't see why
>>>
>>>  -nographic -daemonize
>>>
>>> makes no sence while
>>>
>>>  -curses -daemonize
>>>
>>> does?
>>
>> My vote is that neither of these combinations makes sense.
>
> I agree.  Well, almost -- to me, -curses -daemonize makes much
> less sence than -nographic -daemonize - at least when you think
> about it, ie, when you rely on common sense.  When you look at
> the docs, it becomes apparent that -nographic does something
> else when you thought it is, and so both becomes equally
> non-sentical.
>
> Actually I wanted to error out on -nographic -daemonize (it is "my"
> bug), but after seeing 995ee2bf469de6bbe5ce133ec853392b2a4ce34c
> (which is the "fix" for -curses -daemonize), I decided to fix it
> as well.
>
> So, maybe we should fix both by disallowing both combinations?
> Like the attached patch does?
>
> I'd rather have -nographic work with -daemonize, since the
> alternative - shown in the patch comment - is rather long and
> it is easy to forget to "nullify" some option, while -nographic
> can do that easy and it is convinient, but if people dislikes
> such natural and easy-for-the-user solutions, I wont insist.

Instead of checking just for -nographic or -curses, can we forbid use
of any stdio chardev?

>
> Note that the actual outcome of both is the same -- after using
> either of the two combination (without the above-mentioned fix),
> the terminal switches to raw mode and little can be done with
> it.
>
>
> It is a real PITA that these rather trivial things require so much
> discussing and stays known but unfixed for so long, and much more
> important things gets less time and energy as the result.

Perfect is the enemy of good. It's also too easy to break things since
the design features are not described and tested comprehensively.

>
>
> /mjt



reply via email to

[Prev in Thread] Current Thread [Next in Thread]