qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Serial port hacking


From: Nile Geisinger
Subject: Re: [Qemu-devel] Serial port hacking
Date: Sun, 15 Aug 2004 19:37:25 +0000
User-agent: KMail/1.6

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,





reply via email to

[Prev in Thread] Current Thread [Next in Thread]