From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47914) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QkvI4-00086d-0E for qemu-devel@nongnu.org; Sun, 24 Jul 2011 05:48:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QkvI2-0001RJ-Oh for qemu-devel@nongnu.org; Sun, 24 Jul 2011 05:48:03 -0400 Received: from cantor2.suse.de ([195.135.220.15]:36507 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QkvI2-0001RD-Gs for qemu-devel@nongnu.org; Sun, 24 Jul 2011 05:48:02 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alexander Graf In-Reply-To: <4E2B1CEB.5040606@codemonkey.ws> Date: Sun, 24 Jul 2011 11:47:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1310633908-11520-1-git-send-email-cyliu@novell.com> <4E2AE76A.1050302@codemonkey.ws> <7740093E-1D7B-4D0C-8D77-5C9126BCB52D@suse.de> <4E2B1CEB.5040606@codemonkey.ws> 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 Liguori Cc: Chunyan Liu , qemu-devel@nongnu.org On 23.07.2011, at 21:11, Anthony Liguori wrote: > On 07/23/2011 01:31 PM, Alexander Graf wrote: >>=20 >> On 23.07.2011, at 17:23, Anthony Liguori wrote: >>=20 >>> On 07/14/2011 03:58 AM, Chunyan Liu wrote: >>>> Add "tee" backend to char device. It could be used as follows: >>>> -serial tee:filepath,pty >>>> -chardev = tee,tee_fpath=3Dpath,tee_backend=3Dpty,,path=3Dpath,,[mux=3Don|off] >>>> With "tee" option, "pty" output would be duplicated to filepath. >>>> Related thread: >>>> = http://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg00105.html >>>=20 >>> I loathe adding even more complexity to the the char layer. Can't = you do this just as well with socat? >>=20 >> I disagree. For socat we'd have to open some listening port (unix, = tcg, etc) and then have socat connect to it. >=20 > And what's the problem? Use a unix domain socket and call it a day. >=20 >> While socat is not up yet, the VM won't run. It also adds another = layer of complexity (syncing of socat and qemu process) to the picture = that I don't like. >=20 > 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. >> As long as the tee target is reasonably isolated, I don't think it'd = clutter the char backend. >=20 > 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. > For uncommon use cases where there's another way to do something with = no real obvious technical advantages, using existing code (and = utilities) always wins vs reinventing the wheel IMHO. I tend to agree, but this time the solution in qemu is cleaner and = easier IMHO. Also, I've had issues with tee several times already. In = fact, I actually tried to use tee plenty of times to log console and = debug output to a file while working with Qemu and it randomly just = stopped processing data. While that could be a bug somewhere in one of = the random layers, it shows me how bad complexity grows if you add even = more programs to the puzzle that you can't rely on. 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. Alex