mirror of
https://git.yoctoproject.org/poky
synced 2026-04-21 21:32:12 +02:00
a7d713952e
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: 61682a1a8bfe5f7be6e271a4143fa4a02ca5dca9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 2a87bddabf816d09ec801e33972879e6983627eb) Signed-off-by: Anuj Mittal <anuj.mittal@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.