[Top][All Lists]
[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,