qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3] chardev: add path option for pty backend


From: Paulo Neves
Subject: Re: [PATCH v3] chardev: add path option for pty backend
Date: Thu, 18 Jul 2024 10:04:40 +0000

Peter Maydell <peter.maydell@linaro.org> writes:

      
On Thu, 18 Jul 2024 at 07:15, Markus Armbruster <armbru@redhat.com> wrote:
Looks like this one fell through the cracks.

Octavian Purdila <tavip@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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]