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
