[PATCH] RFC: char: deprecate usage of bidirectional pipe

Gerd Hoffmann kraxel at redhat.com
Tue Aug 16 07:51:17 UTC 2022


On Tue, Jul 26, 2022 at 09:44:25AM +0100, Daniel P. Berrangé wrote:
> On Tue, Jul 26, 2022 at 12:32:32PM +0400, marcandre.lureau at redhat.com wrote:
> > From: Marc-André Lureau <marcandre.lureau at redhat.com>
> > 
> > As Ed Swierk explained back in 2006:
> > https://lists.nongnu.org/archive/html/qemu-devel/2006-12/msg00160.html
> > 
> > "When qemu writes into the pipe, it immediately reads back what it just
> > wrote and treats it as a monitor command, endlessly breathing its own
> > exhaust."
> > 
> > This is similarly confusing when using the chardev with a serial device,
> > as reported in https://bugzilla.redhat.com/show_bug.cgi?id=2106975.
> > 
> > It seems we have kept the support for bidirectional pipes for historical
> > reasons and odd systems, however it's not documented in qemu -chardev
> > options. I suggest to stop supporting it, for portability reasons.
> 
> Hmm, I always assumed that in this scenario the pipe was operating
> in output-only mode. Obviously not the case with the code as it
> exists, but perhaps this would be useful ?  eg its good as a serial
> console logging mechanism at least.

Well, using ${file}.in and ${file}.out has the advantage that it works
fine with all qemu versions.  So adding a warning suggesting to use that
makes sense to me, especially as 7.1 fix.

When looking at longer-term improvements it is probably better to add
support for explicit in/out pipe names, i.e. input= and output=
parameters as suggested later in the thread.  Avoids needing to know
qemu internals (pipe naming convention) and allows to make the input
pipe optional for the logging use case.  That probably is something we
don't want rush into 7.1 though ...

take care,
  Gerd



More information about the libvir-list mailing list