From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BwXa7-00022N-VK for qemu-devel@nongnu.org; Sun, 15 Aug 2004 22:50:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BwXa6-00022B-8c for qemu-devel@nongnu.org; Sun, 15 Aug 2004 22:50:43 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BwXa6-000228-5D for qemu-devel@nongnu.org; Sun, 15 Aug 2004 22:50:42 -0400 Received: from [64.142.16.245] (helo=a.mail.sonic.net) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BwXVP-0006c7-Q9 for qemu-devel@nongnu.org; Sun, 15 Aug 2004 22:45:52 -0400 From: Nile Geisinger Subject: Re: [Qemu-devel] Serial port hacking Date: Sun, 15 Aug 2004 19:37:25 +0000 References: <1092615186.5801.2.camel@unixadmindazfc2.chh.co.nz> In-Reply-To: <1092615186.5801.2.camel@unixadmindazfc2.chh.co.nz> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408151937.25910.nile@dloo.com> Reply-To: nile@dloo.com, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: esrever_otua@pythonhacker.is-a-geek.net, qemu-devel@nongnu.org Hi Darryl, > Whereabouts would I start looking to find the 'glue' code that > connects the emulation of the guest's serial port with the 'real' > world? I've looked briefly at serial.c but it only seemed to deal with > the guts of the emulation, rather that directing its output... I'm reading this question two different ways and I'm not sure which question you're asking, but here's my best shot at both of them. 1) How stdin/stdout are remapped so that linux kernels can run without a gui: ------------------------------- PICTURE ----------------------------------- STDIN/STDOUT -> QEMU -> LINUX KERNEL console This is done in both vl.c and serial.c. In vl.c, there is a function called serial_open_device that returns 0 if the no_graphic option is set. This is called in pc.c when it sets up the first serial port by calling serial_init and passing in 0 (STDOUT). In serial_init, the variable out_fd of the serial console is also set to STDIN (i.e., 1). This serial device is then *seen* by the operating system as the first serial device when it boots. In this way, when we pass the options: -nographic -append "console=ttyS0" we tell the guest kernel to use ttyS0, our serial device, which is connected to the host's STDOUT and STDIN as the console. All of this is fairly opaque and uncommented [ : but if you look at those functions I think it'll make sense. 2) How to connect a host pseudo-tty to a guest-tty: ------------------------------- PICTURE ----------------------------------- MY PSEUDO -> QEMU -> LINUX KERNEL console -> TTYS1 TTY I believe that this can also be found in serial_open_device. If you look there, you'll see the following code commented out in 0.60: #if 0 char slave_name[1024]; int master_fd, slave_fd; /* Not satisfying */ if (openpty(&master_fd, &slave_fd, slave_name, NULL, NULL) < 0) { fprintf(stderr, "warning: could not create pseudo terminal for serial port\n"); return -1; } fprintf(stderr, "Serial port redirected to %s\n", slave_name); return master_fd; #else Here's one way to do this. Uncomment this code and create a separate if block for it that tests for a flag like INITIALIZE_MY_SERIAL_PORT_NOW (too long, I know) as follows: if (INITIALIZE_MY_SERIAL_PORT_NOW) { char slave_name[1024]; int master_fd, slave_fd; /* Not satisfying */ if (openpty(&master_fd, &slave_fd, slave_name, NULL, NULL) < 0) { fprintf(stderr, "warning: could not create pseudo terminal for serial port\n"); return -1; } fprintf(stderr, "Serial port redirected to %s\n", slave_name); return master_fd; } Now, after initializing the first serial device in pc.c, add the following lines of code. INITIALIZE_MY_SERIAL_PORT_NOW = 1; my_serial_fd = serial_open_device() serial_init(0x2f8, 3, my_serial_fd); This will alias a new serial port to the first available pseudo-tty on the host system which in turn will be available as /dev/ttyS1 (possible S2) on the guest linux kernel. Does this help? Out of curiousity, what are you trying to accomplish? I've also been hacking on serial ports and its possible we're tackling a similar problem, cheers, Nile On Monday 16 August 2004 12:13 am, Darryl Dixon wrote: > Hi, > > Whereabouts would I start looking to find the 'glue' code that > connects the emulation of the guest's serial port with the 'real' > world? I've looked briefly at serial.c but it only seemed to deal with > the guts of the emulation, rather that directing its output... (maybe > I'm just being thick and missing the obvious?) Any pointers and help to > send me in the right direction appreciated. > > Cheers,