Richard Purdie a16d7d2ec6 runqemu: Remove potential lock races around tap device handling
The qemu tap device handling is potentially race ridden. We pass the
fd to the main qemu subprocess which is good as it means the lock is held
as long as the qemu process exists. This means we shouldn't unlock it
ourselves though, only close the file. We also can't delete the file
as we have no idea if qemu is still using it. We could try and obtain
an exclusive new lock, then the file would be safe to unlink but it
doesn't seem worth it.

Also fix the same issue in the port lock code.

(From OE-Core rev: 2a87bddabf816d09ec801e33972879e6983627eb)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2021-07-08 14:58:28 +01:00
2021-07-07 11:39:42 +01:00

QEMU Emulation Targets
======================

To simplify development, the build system supports building images to
work with the QEMU emulator in system emulation mode. Several architectures
are currently supported in 32 and 64 bit variants:

  * ARM (qemuarm + qemuarm64)
  * x86 (qemux86 + qemux86-64)
  * PowerPC (qemuppc only)
  * MIPS (qemumips + qemumips64)

Use of the QEMU images is covered in the Yocto Project Reference Manual.
The appropriate MACHINE variable value corresponding to the target is given
in brackets.
Description
No description provided
Readme 249 MiB