From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LV95c-000296-3I for qemu-devel@nongnu.org; Thu, 05 Feb 2009 13:36:40 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LV95a-00028r-Vs for qemu-devel@nongnu.org; Thu, 05 Feb 2009 13:36:39 -0500 Received: from [199.232.76.173] (port=48068 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LV95Z-00028o-Tp for qemu-devel@nongnu.org; Thu, 05 Feb 2009 13:36:37 -0500 Received: from sj-iport-1.cisco.com ([171.71.176.70]:28212) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1LV95Z-0007S0-Fo for qemu-devel@nongnu.org; Thu, 05 Feb 2009 13:36:37 -0500 Message-ID: <498B3193.106@cisco.com> Date: Thu, 05 Feb 2009 11:36:03 -0700 From: "David S. Ahern" 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> In-Reply-To: <4989776E.1060504@eu.citrix.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: Stefano Stabellini , Michael Tokarev Cc: Marcelo Tosatti , KVM list , Mark Marshall , qemu-devel@nongnu.org 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. Index: trunk/qemu-char.c =================================================================== --- trunk/qemu-char.c (revision 6519) +++ trunk/qemu-char.c (working copy) @@ -1067,17 +1067,17 @@ int *targ = (int *)arg; ioctl(s->fd_in, TIOCMGET, &sarg); *targ = 0; - if (sarg | TIOCM_CTS) + if (sarg & TIOCM_CTS) *targ |= CHR_TIOCM_CTS; - if (sarg | TIOCM_CAR) + if (sarg & TIOCM_CAR) *targ |= CHR_TIOCM_CAR; - if (sarg | TIOCM_DSR) + if (sarg & TIOCM_DSR) *targ |= CHR_TIOCM_DSR; - if (sarg | TIOCM_RI) + if (sarg & TIOCM_RI) *targ |= CHR_TIOCM_RI; - if (sarg | TIOCM_DTR) + if (sarg & TIOCM_DTR) *targ |= CHR_TIOCM_DTR; - if (sarg | TIOCM_RTS) + if (sarg & TIOCM_RTS) *targ |= CHR_TIOCM_RTS; } break; @@ -1085,9 +1085,20 @@ { int sarg = *(int *)arg; int targ = 0; - if (sarg | CHR_TIOCM_DTR) + ioctl(s->fd_in, TIOCMGET, &targ); + targ &= ~(CHR_TIOCM_CTS | CHR_TIOCM_CAR | CHR_TIOCM_DSR + | CHR_TIOCM_RI | CHR_TIOCM_DTR | CHR_TIOCM_RTS); + if (sarg & CHR_TIOCM_CTS) + targ |= TIOCM_CTS; + if (sarg & CHR_TIOCM_CAR) + targ |= TIOCM_CAR; + if (sarg & CHR_TIOCM_DSR) + targ |= TIOCM_DSR; + if (sarg & CHR_TIOCM_RI) + targ |= TIOCM_RI; + if (sarg & CHR_TIOCM_DTR) targ |= TIOCM_DTR; - if (sarg | CHR_TIOCM_RTS) + if (sarg & CHR_TIOCM_RTS) targ |= TIOCM_RTS; ioctl(s->fd_in, TIOCMSET, &targ); } david