[Qemu-devel] [Bug 938552] [NEW] ENH: Inherit ptys, useful output from -serial pty

[Qemu-devel] [Bug 938552] [NEW] ENH: Inherit ptys, useful output from -serial pty

[Craig Ringer]

Public bug reported:

When controlling a qemu instance from another program, it'd be very
useful to be able to have qemu inherit pseudo-tty file descriptors so
they could just be specified on the command line.

It's possible to allocate a pty pair in the master program before
forking and exec'ing qemu and have qemu use that pty, but it's a bit
painful. The master program must call ptsname(...) on the fd of the
slave side and insert the path to the pty device node into qemu's
command line. This doesn't work well in many scripting languages which
lack a ptsname() call; a Linux-specific hack like readlink() of
/proc/self/fd/[slave-fd] is necessary.

If qemu accepted file descriptors for serial I/O this would all be a lot
more flexible, and it wouldn't be limited to ptys either. Just accept a
new format for "-serial" like "-serial fd:7" and have the parent program
not set that FD to close-on-exec.

None of this would be as necessary if qemu's "-serial pty" option was
fully functional. Unfortunately, it doesn't provide any information to
associate the created PTY(s) with their qemu devices, so it's hard to
know which serial port is which, which the monitor device is, etc. See,
eg:

$ qemu -serial pty -serial pty -monitor pty
char device redirected to /dev/pts/6
char device redirected to /dev/pts/7
char device redirected to /dev/pts/8

... which is which? Are they allocated in the order they're specified on
the command line? Nope, because /dev/pts/6 is the monitor in this case.
With more than one device using "pty" a lot of guesswork is involved.

If you're using "-monitor stdio" you can issue an "info chardev" and
parse that to find out what everything else is connected to, but this
shouldn't really be necessary. Ideally the device names would be printed
when a port is redirected to a pty, eg:

$ qemu -serial pty -serial pty -monitor pty
char device compat_monitor0 redirected to /dev/pts/6
char device serial0 redirected to /dev/pts/7
char device serial1 redirected to /dev/pts/8

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/938552

Title:
  ENH: Inherit ptys, useful output from -serial pty

Status in QEMU:
  New

Bug description:
  When controlling a qemu instance from another program, it'd be very
  useful to be able to have qemu inherit pseudo-tty file descriptors so
  they could just be specified on the command line.

  It's possible to allocate a pty pair in the master program before
  forking and exec'ing qemu and have qemu use that pty, but it's a bit
  painful. The master program must call ptsname(...) on the fd of the
  slave side and insert the path to the pty device node into qemu's
  command line. This doesn't work well in many scripting languages which
  lack a ptsname() call; a Linux-specific hack like readlink() of
  /proc/self/fd/[slave-fd] is necessary.

  If qemu accepted file descriptors for serial I/O this would all be a
  lot more flexible, and it wouldn't be limited to ptys either. Just
  accept a new format for "-serial" like "-serial fd:7" and have the
  parent program not set that FD to close-on-exec.

  None of this would be as necessary if qemu's "-serial pty" option was
  fully functional. Unfortunately, it doesn't provide any information to
  associate the created PTY(s) with their qemu devices, so it's hard to
  know which serial port is which, which the monitor device is, etc.
  See, eg:

  $ qemu -serial pty -serial pty -monitor pty
  char device redirected to /dev/pts/6
  char device redirected to /dev/pts/7
  char device redirected to /dev/pts/8

  ... which is which? Are they allocated in the order they're specified
  on the command line? Nope, because /dev/pts/6 is the monitor in this
  case. With more than one device using "pty" a lot of guesswork is
  involved.

  If you're using "-monitor stdio" you can issue an "info chardev" and
  parse that to find out what everything else is connected to, but this
  shouldn't really be necessary. Ideally the device names would be
  printed when a port is redirected to a pty, eg:

  $ qemu -serial pty -serial pty -monitor pty
  char device compat_monitor0 redirected to /dev/pts/6
  char device serial0 redirected to /dev/pts/7
  char device serial1 redirected to /dev/pts/8

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/938552/+subscriptions

[Qemu-devel] [Bug 938552] Re: ENH: Inherit ptys, useful output from -serial pty

[T. Huth]

Looks like a fix for this has been included here:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=586502189edf9fd0f89a83d
... so I think it should be OK to close this ticket now.

** Changed in: qemu
       Status: New => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/938552

Title:
  ENH: Inherit ptys, useful output from -serial pty

Status in QEMU:
  Fix Released

Bug description:
  When controlling a qemu instance from another program, it'd be very
  useful to be able to have qemu inherit pseudo-tty file descriptors so
  they could just be specified on the command line.

  It's possible to allocate a pty pair in the master program before
  forking and exec'ing qemu and have qemu use that pty, but it's a bit
  painful. The master program must call ptsname(...) on the fd of the
  slave side and insert the path to the pty device node into qemu's
  command line. This doesn't work well in many scripting languages which
  lack a ptsname() call; a Linux-specific hack like readlink() of
  /proc/self/fd/[slave-fd] is necessary.

  If qemu accepted file descriptors for serial I/O this would all be a
  lot more flexible, and it wouldn't be limited to ptys either. Just
  accept a new format for "-serial" like "-serial fd:7" and have the
  parent program not set that FD to close-on-exec.

  None of this would be as necessary if qemu's "-serial pty" option was
  fully functional. Unfortunately, it doesn't provide any information to
  associate the created PTY(s) with their qemu devices, so it's hard to
  know which serial port is which, which the monitor device is, etc.
  See, eg:

  $ qemu -serial pty -serial pty -monitor pty
  char device redirected to /dev/pts/6
  char device redirected to /dev/pts/7
  char device redirected to /dev/pts/8

  ... which is which? Are they allocated in the order they're specified
  on the command line? Nope, because /dev/pts/6 is the monitor in this
  case. With more than one device using "pty" a lot of guesswork is
  involved.

  If you're using "-monitor stdio" you can issue an "info chardev" and
  parse that to find out what everything else is connected to, but this
  shouldn't really be necessary. Ideally the device names would be
  printed when a port is redirected to a pty, eg:

  $ qemu -serial pty -serial pty -monitor pty
  char device compat_monitor0 redirected to /dev/pts/6
  char device serial0 redirected to /dev/pts/7
  char device serial1 redirected to /dev/pts/8

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/938552/+subscriptions