From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MM5TF-0004fE-CP for qemu-devel@nongnu.org; Wed, 01 Jul 2009 15:27:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MM5TA-0004dC-MH for qemu-devel@nongnu.org; Wed, 01 Jul 2009 15:27:52 -0400 Received: from [199.232.76.173] (port=43236 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MM5TA-0004d1-Fa for qemu-devel@nongnu.org; Wed, 01 Jul 2009 15:27:48 -0400 Received: from mx2.redhat.com ([66.187.237.31]:34862) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MM5T8-0002sE-37 for qemu-devel@nongnu.org; Wed, 01 Jul 2009 15:27:47 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n61JRicu010381 for ; Wed, 1 Jul 2009 15:27:44 -0400 Message-ID: <4A4BB8AC.9080003@redhat.com> Date: Wed, 01 Jul 2009 21:27:40 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1) References: <20090701162114.GB24296@redhat.com> <4A4B91F7.9010206@redhat.com> <20090701165039.GF24296@redhat.com> <4A4B9D2F.5000607@redhat.com> <20090701185049.GC24144@redhat.com> In-Reply-To: <20090701185049.GC24144@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org On 07/01/09 20:50, Daniel P. Berrange wrote: > On Wed, Jul 01, 2009 at 07:30:23PM +0200, Gerd Hoffmann wrote: >> I *do* see the point of being able to have more than one way to access a >> chardev at the same time. But when building up that infrastructure: >> Why stop half-way through and make it a special hack for vnc? I think >> it would be *far* more useful to make chardevs in qemu work that way all >> the time. > > Ok, if i'm understanding correctly, you're suggesting we change the way > character devices are configured on the CLI, to be split like the NIC > device args > > eg, instead of > > -serial file:/tmp/foo.log,name=serial0 > > we'd do > > -serial name=serial0 -chardev name=serial0,file:/tmp/foo.log > > And allow an 1-m mapping for serial -> chardev args Yes. > This could perhaps be done by having a 'CharDriverState' implementation > that was a multiplexor, and allow further CharDriverState instances to > be added/removed to this multiplexor on the fly. Hmm, don't like that idea. > Thus the CharCaptureOps/State bit of my patch would just be another > CharDriverState impl, that gets added/removed on the fly. I'd keep the CharCaptureOps/State and CharDriverState separation as it is now. CharCapture would probably better named CharBackend or simliar. CharDriverState would simply dispatch to all CharBackends connected. We can keep the old code path working for a while. So we can switch users one by one to the new way. When done zap the old one and make CharDiverState a pure dispatcher for the Backends. > The > CharMonitorOps/State bit would still be needed to allow monitoring > of device creation/deletion. Yes. cheers, Gerd