On Mon, 3 Jun 2024 at 13:56, Daniel P. Berrangé <berra...@redhat.com> wrote:
>
> On Mon, Jun 03, 2024 at 01:23:00PM +0100, Peter Maydell wrote:
> > On Fri, 31 May 2024 at 22:21, Octavian Purdila <ta...@google.com> wrote:
> > >
> > > Add path option to the pty char backend which will create a symbolic
> > > link to the given path that points to the allocated PTY.
> > >
> > > Based on patch from Paulo Neves:
> > >
> > > https://patchew.org/QEMU/1548509635-15776-1-git-send-email-ptsne...@gmail.com/
> > >
> > > Tested with the following invocations that the link is created and
> > > removed when qemu stops:
> > >
> > > qemu-system-x86_64 -nodefaults -mon chardev=compat_monitor \
> > > -chardev pty,path=test,id=compat_monitor0
> > >
> > > qemu-system-x86_64 -nodefaults -monitor pty:test
> > >
> > > Also tested that when a link path is not passed invocations still work,
> > > e.g.:
> > >
> > > qemu-system-x86_64 -monitor pty
> >
> > Could we have some justification here for why the new
> > functionality is useful, please? (e.g. what new use cases
> > it permits).
>
> The PTY paths are dynamically allocated so you can't predict them
> as an app launching QEMU. You need to connect to the monitor and
> interogate QEMU to find the path. So supporting a symlink simplifies
> usage.
>
> This was explained in the original patches' commit message, and
> that description should have been kept.
Sounds good. We could add that to the documentation also:
> > > ``pty`` is not available on Windows hosts.
> > >
> > > + ``path`` specifies the symbolic link path to be created that
> > > + points to the pty device.
> >
> > I think we could usefully make this a little less terse. Perhaps
> > If ``path`` is specified, QEMU will create a symbolic link at
> > that location which points to the new PTY device.
> > ?
This allows you to avoid having to make a query via the QMP
or HMP monitor to find out what the new PTY device path is.
thanks
-- PMM
