From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39296) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpA7X-0006wX-FF for qemu-devel@nongnu.org; Thu, 04 Aug 2011 22:26:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QpA7W-0000bP-2B for qemu-devel@nongnu.org; Thu, 04 Aug 2011 22:26:43 -0400 Received: from novprvlin0050.provo.novell.com ([137.65.248.33]:46877) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpA7V-0000Uh-PJ for qemu-devel@nongnu.org; Thu, 04 Aug 2011 22:26:42 -0400 Message-Id: <4E3BE177020000660002445C@novprvlin0050.provo.novell.com> Date: Thu, 04 Aug 2011 20:26:31 -0600 From: "Chun Yan Liu" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part8EA1F6C7.2__=" Subject: Re: [Qemu-devel] [PATCH V2] Add "tee" option to qemu char device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: anthony@codemonkey.ws, agraf@suse.de Cc: qemu-devel@nongnu.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part8EA1F6C7.2__= Content-Type: multipart/alternative; boundary="=__Part8EA1F6C7.3__=" --=__Part8EA1F6C7.3__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Alex & Anthony, About this issue, how should we proceed? Chunyan >>> Anthony Liguori 07/24/11 9:25 PM >>> On 07/24/2011 04:47 AM, Alexander Graf wrote: > >> These arguments all apply to any possible option. Why not a grep = target? Why not a cut or less target? > > Because they don't make sense. Neither does tee :-) >>> As long as the tee target is reasonably isolated, I don't think it'd = clutter the char backend. >> >> It'll never be tested and end up becoming dead bloat code. > > I'll be extensively tested in Xen code, since that's how Xen will invoke = qemu. If this is being used by Xen as part of Xend, then there's really no=20 point in worrying about complexity because the user will never be=20 exposed to it. > > I tend to agree, but this time the solution in qemu is cleaner and = easier IMHO. Let's compare the typical use-case: qemu -hda linux.img -nographic | tee boot.log vs: qemu -hda linux.img -serial tee:boot.log,stdio I'm not even sure I got the syntax right on the later. > Also, I've had issues with tee several times already. Then we should fix those issues. But I have a hard time believing = there=20 were ever issues. This is just piping. > I'm in favor of putting a tee target into qemu's char layer and I'm sure = it'll become a well used target. It will only be used by Xen and Xen could very easily solve this problem=20= outside of qemu. It adds another twisted command line syntax that will make it harder to=20 generalize later. Regards, Anthony Liguori > > Alex > > --=__Part8EA1F6C7.3__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Alex & Anthony,

About this issue, how should = we proceed?

Chunyan

>>> Anthony Liguori <anthony@= codemonkey.ws> 07/24/11 9:25 PM >>>
On 07/24/2011 04:47 AM, = Alexander Graf wrote:
>
>> These arguments all apply to any = possible option. Why not a grep target? Why not a cut or less target?
= >
> Because they don't make sense.

Neither does tee = :-)

>>> As long as the tee target is reasonably isolated, = I don't think it'd clutter the char backend.
>>
>> It'll = never be tested and end up becoming dead bloat code.
>
> I'll = be extensively tested in Xen code, since that's how Xen will invoke = qemu.

If this is being used by Xen as part of Xend, then there's = really no
point in worrying about complexity because the user will = never be
exposed to it.

>
> I tend to agree, but this = time the solution in qemu is cleaner and easier IMHO.

Let's compare = the typical use-case:

qemu -hda linux.img -nographic | tee = boot.log

vs:

qemu -hda linux.img -serial tee:boot.log,stdio
I'm not even sure I got the syntax right on the later.

> = Also, I've had issues with tee several times already.

Then we = should fix those issues. But I have a hard time believing there
were = ever issues. This is just piping.

> I'm in favor of putting a = tee target into qemu's char layer and I'm sure it'll become a well used = target.

It will only be used by Xen and Xen could very easily solve = this problem
outside of qemu.

It adds another twisted command = line syntax that will make it harder to
generalize later.

Regard= s,

Anthony Liguori

>
> Alex
>
>

<= /body> --=__Part8EA1F6C7.3__=-- --=__Part8EA1F6C7.2__=--