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, ...)
--
error compiling committee.c: too many arguments to function
