Il 14/12/2012 14:18, Gerd Hoffmann ha scritto:
> Hi,
>
>> { 'enum': 'ChardevFileMode', 'data':
>> # pty = console under Windows
>> # serial = tty under POSIX
>> [ 'file', 'pipe', 'parport', 'pty', 'serial' ] }
>
> Hmm, why this enum? I'd stay close to -chardev, i.e. specify the type
> by backend name.
Because...
>> { 'enum: 'ChardevFileSource', 'data':
>> [ 'path', 'fd' ] }
>
> I guess I'd just create a new backend type for file descriptor passing
> instead of fitting that into all the existing ones.
... are you passing a file descriptor for a pipe, a file or a
parallel/serial port?
(pty and console have no arguments, I misremembered).
>> { 'union': 'ChardevBackend', 'data': {
>
> This union thing is new, isn't it?
Yeah, a few months old.
> Makes sense to use that indeed.
>
>> 'socket': 'ChardevSocket',
>> 'udp': 'UDPSocketAddress',
>> 'file': 'ChardevFile',
>> 'null': 'ChardevDummy',
>> 'msmouse': 'ChardevDummy',
>> 'braille': 'ChardevDummy',
>> 'stdio': 'ChardevDummy',
>> 'vc': 'ChardevVC',
>
> I doubt we need them all hotpluggable.
True, but:
1) I believe long term it's good to move away from QemuOpts; it's good
to provide a complete interface even if all we're doing for now is
building QemuOpts out of the struct.
2) most of them have no options and trivial anyway;
3) the complicated ones (socket, file, perhaps udp) are also the useful
ones.
Paolo
