Hi Octavian, You should send a new version with the changes requested by Markus. (we might miss 9.1 though)
On Thu, Jul 18, 2024 at 1:48 PM Markus Armbruster <arm...@redhat.com> wrote: > 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. > > > -- Marc-André Lureau
