On 1/2/19 2:23 AM, Marc-André Lureau wrote: > Hi > > On Sat, Dec 29, 2018 at 2:34 PM Paulo Neves <ptsne...@gmail.com> wrote: >> >> If a user requires a virtual serial device like provided >> by the pty char device, the user needs to accept the >> returned device name. This makes the program need to >> have smarts to parse or communicate with qemu to get the >> pty device. >> With this patch the program can pass the path where >> a symlink to the pty device will be, removing the >> need for 2 way communication or smarts. > > This seems reasonable. Your patch doesn't apply on master, can you rebase it? >
>> +++ b/qapi/char.json >> @@ -224,7 +224,7 @@ >> ## >> # @ChardevHostdev: >> # >> -# Configuration info for device and pipe chardevs. >> +# Configuration info for device, pty and pipe chardevs. >> # >> # @device: The name of the special file for the device, >> # i.e. /dev/ttyS0 on Unix or COM1: on Windows >> @@ -380,7 +380,7 @@ >> 'pipe' : 'ChardevHostdev', >> 'socket' : 'ChardevSocket', >> 'udp' : 'ChardevUdp', >> - 'pty' : 'ChardevCommon', >> + 'pty' : 'ChardevHostdev', > > Better to create a new ChardevPty instead (ChardevHostdev is for host > device, here it is not) A new type with identical member names is indistinguishable in introspection. You could even rename s/ChardevHostdev/ChardevDevice/ for use by both 'pipe' and 'pty', since all the more ChardevHostdev did over ChardevCommon was add a 'device' member (since renaming types is transparent to introspection). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature