qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Nile Geisinger <nile@dloo.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Ugh! Greatly appreciate help.
Date: Thu, 29 Jul 2004 11:19:29 +0000	[thread overview]
Message-ID: <200407291119.29715.nile@dloo.com> (raw)


Pulling my hair out a little on this one. :]. It's probably an obvious 
solution to a reader here, so thanks in advance for any help.

My two questions are:

1. What is the easiest way to send data from qemu (the program, not the host 
os) to a client linux os *without* a network connection?

2. In regards to doing this with serial devices, what mistake am I 
in the code below? Is the qemu serial device writer still on the list or 
anyone familiar with serial programming? I have it working sending data from 
Linux to my serial device in qemu, but am only intermittently successful 
going the other way. My code is included below to show my approach.

thanks in advance for an answer to either question,

Nile

*** Question number two with code ***

Thanks for reading this far. In regards to question two, I'm trying to set up 
a two way communication channel between qemu (the program) and the client 
where the client os is Linux. I need to use a non-net
connection if at all possible. I've added two new serial devices and it's 
mostly working, but I'm having one last difficulty -- getting all the data I 
think I'm putting in the serial device read by the Linux os. 

Here's what I've tried so far. Although I could use one dual-channel serial 
port, I'm intentionally using two (one for reading, one for writing) to 
narrow down on the problem. I add both serial devices as follows
in pc.c:

// Initialize serial port (ttyS1)
serial_init(0x2f8, 3, 0);

// Initialize serial port (ttyS2)
serial_init(0x3e8, 11, 0);

I also added code in serial_init to initialize the devices (Here's the code 
for ttyS1, though I don't think this is where the problem is):

if  (irq == 3)
{
	  /* Create the communication file. */
	  unlink("mycom.txt");
	  input_writeptr = fopen("mycom.txt", "w");
	  fclose(input_writeptr);

	  /* Open up our communication file for non-blocking reading */
	  input_readfd = open("mycom.txt", O_RDONLY | O_NONBLOCK);
          input_layer = s;
          qemu_add_fd_read_handler(input_readfd, serial_can_receive1, 
serial_receive1, s);

	  /* Open up our communication file for writing. */
	  input_writefd = open("mycom.txt", O_WRONLY);
	  s->out_fd = input_writefd ;
}

Linux correctly recognizes both of the serial ports on booting. 

On the client side, the C code that sends information from the linux os 
through port (ttyS2) to the qemu program works correctly and I've written 
code in qemu that prints it out. 

However, the code that sends information from the qemu program through ttyS1 
to the Linux operating system has some bug I'm missing. Data gets dropped
intermittently. I think I am making either one of two problems: sending 
information in qemu wrong to that serial device or reading it wrong in the C 
code on the linux side. This may be based on the fact that I'm new to serial 
port programming and qemu. 

Here are the two places I've sent information from qemu:

-> in the inner loop of vl.c as it cycles through devices and performs its 
read and then calls fd_read I pass it the info I want to send. For example:

	// Don't touch regular devices
	if (ioh->opaque != my_output_device)
	{
		n = read(ioh->fd, buf, ioh->max_size);
	}
	// This is our device: Directly set n and the input buffer so that fd_read 
can
	// be passed them.
	else {
		n = strlen(myinfo);
		strcpy(buf, myinfo, n);
	}
		
-> Alternatively, in serial_ioport_read when that specific device is called 
with case 0, I change the variable 'ret' to the character I want to send. For 
example:

	if (s != my_output_device)
	{
		ret = s->rbr; // Original code
	}
	else
	{
		ret = get_character_to_send(); 	// Directly set the variable 'ret'
		s->rbr = ret;
	}
	
Either way, the result is that data is dropped somewhere from where qemu
is sending it here to the program on the linux client trying to read it. The 
linux C code will read a few continuous bytes of information, then skip 10 
bytes, read a few more and skip another random set of bytes. My code on the 
linux side also seems fairly standard:

	fd = open(argv[1], O_RDONLY);
	tcgetattr(fd, tp);

        tp.c_cflag = CS8|CLOCAL|baud|CREAD;
        tp.c_oflag = 0;
        tp.c_iflag = IGNCR|IGNPAR;
        tp.c_lflag = 0;

        cfsetospeed(&tp, baud);
        cfsetispeed(&tp, baud);
        if (tcsetattr(fd, TCSANOW, &tp) < 0) {
                perror("Couldn't set term attributes");
                exit(-1);
	}

        n = read(fd, readBuffer, 6);

I've also tried this with O_NONBLOCK (i.e., non-blocking read), but it has the 
same problem of reading a few continuous bytes, then skipping a segment. 

Can anyone see my mistake or have any ideas to make it possible for the Linux
side to continually read all the data?

                 reply	other threads:[~2004-07-29 18:28 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200407291119.29715.nile@dloo.com \
    --to=nile@dloo.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).