On 08/01/2011 04:54 PM, Blue Swirl wrote:
On Mon, Aug 1, 2011 at 2:22 PM, Anthony Liguori<aligu...@us.ibm.com> wrote:
The char layer has been growing some nasty warts for some time now as we ask it
to do things it was never intended on doing. It's been long over due for an
overhaul and its become evident to me that we need to address this first before
adding any more features to the char layer.
This series is the start at sanitizing the char layer. It effectively turns
the char layer into an internal pipe. It supports flow control using an
intermediate ring queue for each direction.
This series is an RFC because I don't think we should merge the series until we
completely convert the old style flow control users to the new style.
The terms 'back-end' and 'front-end' could be improved. How about just
'device' or 'hw' and 'chrdev'?
It's all temporary as there currently is very little asymmetry.
Historically, the biggest source of asymmetry was the fact that the
back-end -> front-end path had flow control and the opposite direction
didn't.
This series fixes that. The only remaining asymmetry is the ioctl()
call. I think if we change the semantics of qemu_chr_event() though to
have a return value and a data parameter, I think we can fold ioctl into
event and ultimately fix that asymmetry.
Once that's done, there's no longer a distinction between front-end and
back-end. That makes CharDriverState act as basically a socketpair().
The architecture could be described in for example qemu-tech.texi.
I'll include something for docs/ for the next submission.
Regards,
Anthony Liguori
