qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH for-1.4] qapi: Improve chardev-add documentation


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH for-1.4] qapi: Improve chardev-add documentation
Date: Tue, 12 Feb 2013 10:44:18 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

[cc'ing Paolo]

Gerd Hoffmann <address@hidden> writes:

> On 02/11/13 18:16, Markus Armbruster wrote:
>> Apropos chardev-add schema.  I know I gave up whatever bikeshedding
>> privileges I might have by not reviewing the series before it went in,
>> but here goes anyway: I don't like the name ChardevPort.  'Port' tells
>> me nothing.  It's really host character device passthrough, isn't it,
>> Gerd?
>
> ChardevPort is more or less taken from Paolos qapi interface draft, and
> I found it intuitive enough to go with it.  This is about passing
> through serial (and parallel) *ports* to the guest.  And, yes, it works
> for other tty devices too, so you don't always have a physical port.

What's the distinctive property of ChardevPort things?

Same question worded differently: what other things would we want to
stuff into this (type, device) object rather than elsewhere?

I'd say the distinctive bit is "'device' names a host character device".
If we find another host character device we want to pass through, we'd
almost certainly put it into ChardevPort, wouldn't we?

Aside: 'type' is only there because we can't be bothered to figure out
the device type ourselves.  Lame.

Exception: pseudoterminals.  They don't fit, because you don't open them
by name.  But they're so special they already got their own
ChardevBackend type.

Now let's take another step back: a character device is just a file.
Why can't we use plain ChardevFile for it?

File type could be determined automatically.  If we don't want to do
that, we have to make the user specify it via parameter.  The parameter
could be optional and default to "regular file".

> So, if you have a better name suggestion in time for 1.4 ...

I believe the cautious choice is disabling type port for 1.4, so we can
figure out the design we want without undue time pressure.

Disabling it for 1.4 shouldn't be a big deal, because the QMP command is
not yet feature complete anyway.

If we decide to keep it for 1.4, I'd suggest to rename from 'port' to
'hostdev' or similar.



reply via email to

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