Peter Maydell <peter.mayd...@linaro.org> writes: > On Thu, 18 Jul 2024 at 07:15, Markus Armbruster <arm...@redhat.com> wrote: >> >> Looks like this one fell through the cracks. >> >> Octavian Purdila <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. Some advice on robust use of @path could be useful, in particular on guarding against QEMU leaving stale links behind. Additional decision: whether to extend the old-style syntax.
