Re: [Qemu-devel] Serial port hacking

[Nile Geisinger <nile@dloo.com>]

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,