From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LUfgO-0007pz-GC for qemu-devel@nongnu.org; Wed, 04 Feb 2009 06:12:40 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LUfgM-0007pd-8M for qemu-devel@nongnu.org; Wed, 04 Feb 2009 06:12:39 -0500 Received: from [199.232.76.173] (port=39109 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUfgM-0007pa-1S for qemu-devel@nongnu.org; Wed, 04 Feb 2009 06:12:38 -0500 Received: from smtp.eu.citrix.com ([62.200.22.115]:11803) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LUfgL-00013z-Mf for qemu-devel@nongnu.org; Wed, 04 Feb 2009 06:12:37 -0500 Message-ID: <4989776E.1060504@eu.citrix.com> Date: Wed, 04 Feb 2009 11:09:34 +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> In-Reply-To: <498953BA.7060407@msgid.tls.msk.ru> 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: Michael Tokarev Cc: qemu-devel@nongnu.org, Marcelo Tosatti , "David S. Ahern" , Mark Marshall , KVM list 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.