Peter Maydell [<peter.mayd...@linaro.org>](mailto:peter.mayd...@linaro.org) writes:
>> On Thu, 18 Jul 2024 at 07:15, Markus Armbruster >> [<arm...@redhat.com>](mailto:arm...@redhat.com) >> wrote: >> >>> Looks like this one fell through the cracks. >>> >>> Octavian Purdila >>> [<ta...@google.com>](mailto:ta...@google.com) >>> writes: >>> >>>> Add path option to the pty char backend which will create a symbolic >>>> link to the given path that points to the allocated PTY. >>>> >>>> This avoids having to make QMP or HMP monitor queries to find out what >>>> the new PTY device path is. >>> >>> QMP commands chardev-add and chardev-change return the information you >>> want: >>> >>> # @pty: name of the slave pseudoterminal device, present if and only >>> # if a chardev of type 'pty' was created >>> >>> So does HMP command chardev-add. HMP chardev apparently doesn't, but >>> that could be fixed. >>> >>> So, the use case is basically the command line, right? >> >>> The feature feels rather doubtful to me, to be honest. >> >> The command line is an important use-case, though. Not every >> user of QEMU is libvirt with a QMP/HMP connection readily >> to hand that they would prefer to use for all configuration... > > In general yes. But what are the use cases for this one? > > To me, specifying path=/mumble/symlink plus the bother of cleaning up > stale ones doesn't feel like much of an improvement over reading the pty > name from "info chardev". I guess I'm missing something. Tell me! > > If we decide we want this, then the QMP interface needs to be fixed: > Call the argument @path for consistency, and document it properly. > Actually straightforward, just create a new struct instead of pressing > ChardevHostdev into service. The original use case was not about reading the path but allowing the caller to set the symlink. The cleaning up and ergonomics of handling that path are besides the point of the patch. In my case it was a path I could define in configuration and let other services use that chardev. Other services that did not require knowledge of whether the PTY was real or from QEMU and thus did not know how to query it.
