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: Markus Armbruster
Subject: Re: [PATCH v3] chardev: add path option for pty backend
Date: Thu, 18 Jul 2024 11:47:32 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

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.

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.




reply via email to

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