From owner-freebsd-virtualization@freebsd.org Tue Jul 12 00:39:29 2016 Return-Path: Delivered-To: freebsd-virtualization@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F507B92D34 for ; Tue, 12 Jul 2016 00:39:29 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2DC661F43 for ; Tue, 12 Jul 2016 00:39:28 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from [24.104.150.22] (unknown [24.104.150.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 943863AF8E; Tue, 12 Jul 2016 00:39:27 +0000 (UTC) Message-ID: <57843C3D.80102@redbarn.org> Date: Mon, 11 Jul 2016 17:39:25 -0700 From: Paul Vixie User-Agent: Postbox 4.0.8 (Windows/20151105) MIME-Version: 1.0 To: Jakub Klama CC: freebsd-virtualization@freebsd.org Subject: Re: [Differential] D7185: Add virtio-console support to bhyve References: <5783D6FF.7010107@redbarn.org> <5783E2FE.1040309@redbarn.org> <5783E64B.9010608@redbarn.org> <6B5AEBF8-98B0-4031-A3E3-A1EBC8B4B763@uj.edu.pl> <57841572.7060903@redbarn.org> <577FFDDF-7EC5-4143-AA1B-858BA8C3287F@uj.edu.pl> In-Reply-To: <577FFDDF-7EC5-4143-AA1B-858BA8C3287F@uj.edu.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 00:39:29 -0000 Jakub Klama wrote: > It doesn't speak any protocol. virtio-console is a pipe. it pushes > bytes back and forth. Name is indeed unfortunate, it should have > been called virtio-pipe, but virtio-console is how the virtio > specification calls it. if it's never going to appear as /dev/console or any other tty-like device to the guest, then i won't care what it looks like on the host. however, you said it could carry resize events, which leads me to believe that the name (vertio-console) is not wrong, and it is a tty to the guest, and in my view that means it should be a tty to the host. please explain how your proposed addition to bhyve handles resize events but is not actually related to tty use by either the guest or host. > If we were to use virtio-console as a system console, then using a > pseudo tty and forwarding pty resize notifications as resize control > events to the guest is totally fine and desired (at least as one of > the options). However, as I said, unix domain socket is perfect fit > for using is at a regular bidirectional pipe. if that pipe has resize events encoded in it, as you said earlier, then it has to have a protocol, and it is not just a bidirectional pipe. please explain more about your use case. what will this device look like to the guest, and what application do you expect to have running on the host to talk to this unix domain socket? -- P Vixie