From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LVBF5-0003VT-4f for qemu-devel@nongnu.org; Thu, 05 Feb 2009 15:54:35 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LVBF4-0003VF-MS for qemu-devel@nongnu.org; Thu, 05 Feb 2009 15:54:34 -0500 Received: from [199.232.76.173] (port=41100 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LVBF4-0003VC-HL for qemu-devel@nongnu.org; Thu, 05 Feb 2009 15:54:34 -0500 Received: from smtp.eu.citrix.com ([62.200.22.115]:21019) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LVBF2-00018i-O8 for qemu-devel@nongnu.org; Thu, 05 Feb 2009 15:54:33 -0500 Message-ID: <498B5121.4020103@eu.citrix.com> Date: Thu, 05 Feb 2009 20:50:41 +0000 From: Stefano Stabellini MIME-Version: 1.0 References: <497E1B15.2090908@msgid.tls.msk.ru> <497E1F7D.90300@msgid.tls.msk.ru> <49876547.1080904@cisco.com> <49876678.4090808@msgid.tls.msk.ru> <4987674E.9050201@cisco.com> <4987FCBA.7020104@msgid.tls.msk.ru> <4988032A.5010905@ntlworld.com> <20090204080942.GA3640@amt.cnet> <498953BA.7060407@msgid.tls.msk.ru> <4989776E.1060504@eu.citrix.com> <498B3193.106@cisco.com> In-Reply-To: <498B3193.106@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: more about serial ports: do they even work? Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "David S. Ahern" Cc: Marcelo Tosatti , Michael Tokarev , KVM list , Mark Marshall , qemu-devel@nongnu.org David S. Ahern wrote: > > Stefano Stabellini wrote: >> Michael Tokarev wrote: >> >>> Other than that, an.. excellent idea, I wanted to propose >>> just that when I first saw all this stuff, but was somewhat >>> afraid. And I *think* there's at least *some* sense. Qemu >>> is a CPU emulator and may work on another arch where those >>> bits are defined differently. Maybe that was the reason for >>> all this converting - to be safe than sorry, so to say. No? >>> >> Yes, this is exactly the reason why they were introduced in the first place. >> Let's suppose that the guest defines those constants differently: we >> need to parse them and covert them appropriately to the host format. >> CHR_IOCTL_SERIAL_SET_TIOCM and CHR_TIOCM_DTR correspond to the guest >> version of TIOCMSET and TIOCM_DTR and can be defined differently >> depending on the particular guest arch. > > The following works for me. It fixes the existing checks in place for > the GET and replicates that for the SET. The ioctl initialization is > needed in the SET is needed. It looks pretty good to me. Acked-by: stefano.stabellini@eu.citrix.com