Commit Message

This driver handles in-memory qemu-char driver operations, that's,
all writes to this driver are stored in an internal buffer. The
driver doesn't talk to the external world in any way.
Right now it's very simple: it supports only writes. But it can
be easily extended to support more operations.
This driver is going to be used by the monitor subsystem, which
needs to 'emulate' a qemu-char device, so that monitor handlers
can be ran without a backing device and have their output stored.
TODO: Move buffer growth logic to cutils.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
---
qemu-char.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
qemu-char.h | 6 +++++
2 files changed, 74 insertions(+), 0 deletions(-)

Luiz Capitulino <lcapitulino@redhat.com> writes:
> On Wed, 10 Nov 2010 13:56:39 +0100> Markus Armbruster <armbru@redhat.com> wrote:>>> Luiz Capitulino <lcapitulino@redhat.com> writes:>> >> > On Wed, 10 Nov 2010 10:26:15 +0100>> > Markus Armbruster <armbru@redhat.com> wrote:
[...]
>> >> Unlike normal character drivers, this one can't be closed with>> >> qemu_chr_close(), can it? What happens if someone calls>> >> qemu_chr_close() on it?>> >>> > I guess it will explode, because this driver is not in the chardevs list>> > and our CharDriverState instance is allocated on the stack.>> >>> > Does a function comment solves the problem or do you have something else>> > in mind?>> >> A general OO rule: Having different constructors for different sub-types>> is okay, but once constructed, you should be able to use the objects>> without knowing of what sub-type they are. That includes destruction.>> We will have to add our MemoryDriver to the chardevs list, this has some> implications like being visible in qemu_chr_info() and qemu_chr_find(),> likely to also imply that we should choose a chr->filename.
Not if we formalize the notion of an "internal use only" character
device. Say, !chr->filename means it's internal, and internal ones
aren't in chardevs. Make qemu_chr_close()'s QTAILQ_REMOVE() conditional
!chr->filename.
> Another detail is that we'll have to dynamically alocate our CharDriverState> instance. Not a problem, but adds a few more lines of code and a> qemu_free(). None of this is needed today.
I doubt the alloc/free matters.
> Really worth it?
Your call.
But if you decide not to, please add a suitable assertion to
qemu_chr_close(), to make it obvious what went wrong when an internal
character device explodes there.
>> Exceptions prove the rule. Maybe this is one, maybe not.
[...]

On Wed, 10 Nov 2010 14:33:47 +0100
Markus Armbruster <armbru@redhat.com> wrote:
> Luiz Capitulino <lcapitulino@redhat.com> writes:> > > On Wed, 10 Nov 2010 13:56:39 +0100> > Markus Armbruster <armbru@redhat.com> wrote:> >> >> Luiz Capitulino <lcapitulino@redhat.com> writes:> >> > >> > On Wed, 10 Nov 2010 10:26:15 +0100> >> > Markus Armbruster <armbru@redhat.com> wrote:> [...]> >> >> Unlike normal character drivers, this one can't be closed with> >> >> qemu_chr_close(), can it? What happens if someone calls> >> >> qemu_chr_close() on it?> >> >> >> > I guess it will explode, because this driver is not in the chardevs list> >> > and our CharDriverState instance is allocated on the stack.> >> >> >> > Does a function comment solves the problem or do you have something else> >> > in mind?> >> > >> A general OO rule: Having different constructors for different sub-types> >> is okay, but once constructed, you should be able to use the objects> >> without knowing of what sub-type they are. That includes destruction.> >> > We will have to add our MemoryDriver to the chardevs list, this has some> > implications like being visible in qemu_chr_info() and qemu_chr_find(),> > likely to also imply that we should choose a chr->filename.> > Not if we formalize the notion of an "internal use only" character> device. Say, !chr->filename means it's internal, and internal ones> aren't in chardevs. Make qemu_chr_close()'s QTAILQ_REMOVE() conditional> !chr->filename.
Yes, it's doable. But this kind of change will make this series intrusive,
for example, is it really impossible to create !chr->filename via the
normal means (eg. from the user)? What if we break something else with this
change?
> > Another detail is that we'll have to dynamically alocate our CharDriverState> > instance. Not a problem, but adds a few more lines of code and a> > qemu_free(). None of this is needed today.> > I doubt the alloc/free matters.> > > Really worth it?> > Your call.
I don't think so, unless we have a real need for it (and this can be done
later anyway).
> But if you decide not to, please add a suitable assertion to> qemu_chr_close(), to make it obvious what went wrong when an internal> character device explodes there.> > >> Exceptions prove the rule. Maybe this is one, maybe not.> [...]>