qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 01/12] char: rename qemu_chr_write() to qemu_chr


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 01/12] char: rename qemu_chr_write() to qemu_chr_fe_write()
Date: Thu, 04 Aug 2011 11:21:25 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

On 08/04/2011 11:14 AM, Avi Kivity wrote:
On 08/04/2011 07:11 PM, Anthony Liguori wrote:
On 08/04/2011 11:00 AM, Avi Kivity wrote:
On 08/01/2011 05:22 PM, Anthony Liguori wrote:
The char layer is confusing. There is a front-end, typically a device,
that
can send and receive data. The front-end sends data by calling
qemu_chr_write().

The back-end, typically created via -chardev, can also send and
receive data.
Oddly, it sends data by calling qemu_chr_read().

Let's be explicit about which function is for which party.

A different way to accomplish this would be to have each pipe expose two
interfaces (a front end and a back end), and use the same functions for
both. Just like a unix pipe.

This is exactly what I'm trying to do. This is why I decided to do
this before QOM, because this will change the relationships between
objects dramatically since you no longer need to subclass
CharDriverState since it's just being used as a pipe.

Yes, I'm just talking about the function names, not about the
implementation.

qemu_chr_fe_write(chr,...) -> qemu_chr_write(chr, ...)
qemu_chr_be_write(chr, ...) -> qemu_chr_write(&chr->backend, ...)

These are just the incremental patches to get us there. Some more refactoring is needed to get to a single function.

Regards,

Anthony Liguori



reply via email to

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