|
Hi,
This patch adds a single plugin, contrib/plugins/dlcall.c (~240 lines,
no changes to QEMU core), that lets a linux-user guest call functions in the
host's native shared libraries instead of emulating them.
It is the natural next step on top of the vCPU syscall-filter callback that I
contributed and that was merged earlier:
https://lore.kernel.org/qemu-devel/20251214144620.179282-1-functioner@sjtu.edu.cn/
Why bother? Because it turns slow, instruction-by-instruction emulation of a
library into a native host call. Some results, all on completely unmodified
guest binaries:
* minizip (the stock zlib utility) compresses several times faster, because
the actual deflate runs natively on the host instead of being translated.
* Real OpenGL/Vulkan games run under qemu-user: SuperTuxKart and Hollow
Knight are playable, with their graphics calls going straight to the host
GPU.
How it works
============
The guest makes a system call with a reserved number (4096 by default) that no
real Linux ABI uses. Its first argument selects a pass-through operation, and the
rest carry operands:
syscall(4096, op, arg1, arg2, ...)
| | \............ operands (pointers / values)
| \................. which pass-through operation
\....................... the reserved "magic" number
The plugin registers a vCPU syscall filter: before QEMU forwards a syscall to
the host kernel, the filter runs, sees 4096, performs the operation on the
host, writes the result back, and tells QEMU the syscall is consumed, so the
real kernel never sees it.
The whole interface is just a handful of primitives:
* query a host attribute
* dlopen / dlclose a host shared library
* dlsym a symbol, and read the last dlerror
* invoke a resolved host function with a void(void *, void *) signature
That is all the plugin does. It knows nothing about zlib, X11 or OpenGL, or
about any library's calling convention.
The same machinery also runs in reverse: when a host function needs to call
back into the guest (a qsort comparator, an allocator, a GUI or game callback),
control re-enters the guest to run the callback and then resumes the suspended
host call. This reentry is what lets stateful, callback-driven APIs work, not
just leaf functions.
Why the plugin belongs in QEMU, and the rest does not
=====================================================
Only the plugin lives in the tree. Everything else is ordinary userspace:
--- userspace (out of tree, not tied to any DBT) -------------
guest: unmodified program -> guest runtime + thunk libs
--------------------------------------------------------------
| syscall(4096, op, args) (only crossing point)
v
=== inside QEMU: THIS PATCH, ~240 lines ======================
dlcall plugin: dlopen / dlsym / invoke a host fn
==============================================================
|
v
--- userspace (out of tree) ----------------------------------
host: host runtime + thunk libs -> real libz / libGL ...
--------------------------------------------------------------
The split is deliberate, and it is why only this one file is proposed for the
tree:
* This plugin defines the most general interaction interface for native
pass-through: the magic-syscall ABI between an emulated guest and its
emulator. That contract is what every pass-through implementation builds
on, so it belongs in a stable, shared place.
* It is also the only piece that is inherently QEMU-specific: it plugs into
QEMU's syscall-filter hook and runs inside the QEMU process. The argument
marshalling, calling conventions, callbacks/reentry and per-library
coverage are not tied to any particular DBT and behave as ordinary
userspace, so they should stay out of tree rather than couple QEMU to them.
Background: we presented this approach at KVM Forum 2025, "Lorelei: Enable QEMU
to Leverage Native Shared Libraries":
https://www.youtube.com/watch?v=_jioQFm7wyU
The userspace side
==================
A fair point on v3 was that, on its own, the plugin is only half of an
interface: useful only if the other half (the guest/host runtimes and the
per-library thunks) is public and specified, rather than a private demo. That
half is now available as a standalone, documented, CI-tested project, Lorelei:
https://github.com/rover2024/lorelei
Lorelei provides the guest and host runtimes and a Thunk Library Compiler
(TLC, built on Clang LibTooling) that reads a library's headers and generates
the guest and host thunks automatically, including the awkward cases of
function-pointer callbacks and variadic functions. It has CI for x86_64, arm64
and riscv64 hosts. Lorelei and its thunk libraries are MIT-licensed.
Because the plugin is not upstream yet, Lorelei currently builds and tests
against the QEMU fork that carries it.
The plugin stays deliberately minimal and prescribes nothing about how
thunking is done. Lorelei is one reference implementation of the userspace
side. Any toolchain, or another instrumentation framework, can implement the
same dlcall interface.
A from-scratch walkthrough of the bare mechanism, with the minizip and
OpenGL/X11 examples above, is also available here:
https://github.com/rover2024/qemu-passthrough-test
It is fully opt-in (loaded with -plugin) and targets linux-user, where the
guest and host already share a trust domain. The test cases use x86_64 guests
and run on x86_64, arm64 and riscv64 Linux hosts.
I have deliberately kept Lorelei out of the patch itself: neither the code
nor its comments mention it, since I am not sure whether referencing an
external project from the tree is welcome. I would appreciate guidance on
where a pointer to the toolchain belongs, if anywhere. For example, would it
be appropriate to mention it from the documentation patch?
Feedback on the plugin and on the pass-through approach is welcome.
Changes since v3:
* Lorelei, the userspace toolchain that implements this interface, is now a
public, documented, CI-tested project, with a Thunk Library Compiler that
generates the guest/host thunks automatically. This addresses the v3
feedback that the interface needs a public implementation behind it. The
plugin code itself is unchanged.
* The documentation patch is held back for now.
Changes since v2:
* Dropped the RFC tag. The approach was positively received on v2.
* Rebased on master and adjusted the syscall-filter callback to its updated
signature (int64_t sysret, added userdata, dropped the plugin id
argument).
Changes since v1:
* Renamed the plugin from "passthrough" to "dlcall" (Pierrick Bouvier).
The old name was too generic. The name "dlcall" reflects what the plugin actually
does (dlopen/dlsym a host symbol and call it) and avoids confusion with
QEMU's existing plugin hostcall concept (QEMU_PLUGIN_*_HOSTCALL).
* Made the magic syscall number configurable at load time via the
"syscall_num=N" argument, defaulting to 4096 and rejecting values low
enough to clash with a real syscall (Pierrick Bouvier).
v1: https://lore.kernel.org/qemu-devel/20260617130742.769234-1-functioner@sjtu.edu.cn/
v2: https://lore.kernel.org/qemu-devel/20260619045404.820960-1-functioner@sjtu.edu.cn/
v3: https://lore.kernel.org/qemu-devel/20260622163438.130746-1-functioner@sjtu.edu.cn/
Thanks,
Ziyang Zhang
Ziyang Zhang (1):
contrib/plugins: add a minimal dlcall plugin
contrib/plugins/dlcall.c | 238 ++++++++++++++++++++++++++++++++++++
contrib/plugins/meson.build | 5 +
2 files changed, 243 insertions(+)
create mode 100644 contrib/plugins/dlcall.c
--
2.34.1
On 6/29/2026 9:02 AM, Ziyang Zhang wrote: > Hi, > > This patch adds a single plugin, contrib/plugins/dlcall.c (~240 lines, > no changes to QEMU core), that lets a linux-user guest call functions in the > host's native shared libraries instead of emulating them. > > It is the natural next step on top of the vCPU syscall-filter callback that I > contributed and that was merged earlier: > > https://lore.kernel.org/qemu-devel/20251214144620.179282-1-functioner@sjtu.edu.cn/ > > Why bother? Because it turns slow, instruction-by-instruction emulation of a > library into a native host call. Some results, all on completely unmodified > guest binaries: > > * minizip (the stock zlib utility) compresses several times faster, because > the actual deflate runs natively on the host instead of being translated. > * Real OpenGL/Vulkan games run under qemu-user: SuperTuxKart and Hollow > Knight are playable, with their graphics calls going straight to the host > GPU. > > How it works > ============ > > The guest makes a system call with a reserved number (4096 by default) that no > real Linux ABI uses. Its first argument selects a pass-through operation, and the > rest carry operands: > > syscall(4096, op, arg1, arg2, ...) > | | \............ operands (pointers / values) > | \................. which pass-through operation > \....................... the reserved "magic" number > > The plugin registers a vCPU syscall filter: before QEMU forwards a syscall to > the host kernel, the filter runs, sees 4096, performs the operation on the > host, writes the result back, and tells QEMU the syscall is consumed, so the > real kernel never sees it. > > The whole interface is just a handful of primitives: > > * query a host attribute > * dlopen / dlclose a host shared library > * dlsym a symbol, and read the last dlerror > * invoke a resolved host function with a void(void *, void *) signature > > That is all the plugin does. It knows nothing about zlib, X11 or OpenGL, or > about any library's calling convention. > > The same machinery also runs in reverse: when a host function needs to call > back into the guest (a qsort comparator, an allocator, a GUI or game callback), > control re-enters the guest to run the callback and then resumes the suspended > host call. This reentry is what lets stateful, callback-driven APIs work, not > just leaf functions. > > Why the plugin belongs in QEMU, and the rest does not > ===================================================== > > Only the plugin lives in the tree. Everything else is ordinary userspace: > > --- userspace (out of tree, not tied to any DBT) ------------- > guest: unmodified program -> guest runtime + thunk libs > -------------------------------------------------------------- > | syscall(4096, op, args) (only crossing point) > v > === inside QEMU: THIS PATCH, ~240 lines ====================== > dlcall plugin: dlopen / dlsym / invoke a host fn > ============================================================== > | > v > --- userspace (out of tree) ---------------------------------- > host: host runtime + thunk libs -> real libz / libGL ... > -------------------------------------------------------------- > > The split is deliberate, and it is why only this one file is proposed for the > tree: > > * This plugin defines the most general interaction interface for native > pass-through: the magic-syscall ABI between an emulated guest and its > emulator. That contract is what every pass-through implementation builds > on, so it belongs in a stable, shared place. > * It is also the only piece that is inherently QEMU-specific: it plugs into > QEMU's syscall-filter hook and runs inside the QEMU process. The argument > marshalling, calling conventions, callbacks/reentry and per-library > coverage are not tied to any particular DBT and behave as ordinary > userspace, so they should stay out of tree rather than couple QEMU to them. > > Background: we presented this approach at KVM Forum 2025, "Lorelei: Enable QEMU > to Leverage Native Shared Libraries": > > https://www.youtube.com/watch?v=_jioQFm7wyU > > The userspace side > ================== > > A fair point on v3 was that, on its own, the plugin is only half of an > interface: useful only if the other half (the guest/host runtimes and the > per-library thunks) is public and specified, rather than a private demo. That > half is now available as a standalone, documented, CI-tested project, Lorelei: > > https://github.com/rover2024/lorelei > > Lorelei provides the guest and host runtimes and a Thunk Library Compiler > (TLC, built on Clang LibTooling) that reads a library's headers and generates > the guest and host thunks automatically, including the awkward cases of > function-pointer callbacks and variadic functions. It has CI for x86_64, arm64 > and riscv64 hosts. Lorelei and its thunk libraries are MIT-licensed. > Thanks for publishing it. A few ideas to make Lorelei even more easy to use: Would that be possible to add binary artifacts to the existing 1.0.0 Lorelei release? Ideally, it should provide a toolchain (for x64 hosts) with support for x64, arm64 and riscv64 guest thunks. Also, would that possible to provide a script to generate boilerplate for thunks, and extract list of symbols from a given library? My ultimate goal would be to have something as simple as: $ wget toolchain.hostx64.tar.gz # automatically generate boilerplate + compile guest/host thunks $ toolchain.hostx64/bin/generate-thunks \ --arch arm64 --library /usr/lib/libfoo.so \ --header /usr/include/foo.h --out thunks_arm64 $ aarch64-linux-gnu-gcc main.c -lfoo $ env LD_LIBRARY_PATH=./thunks_arm64 \ qemu-arm64 ./a.out -plugin contrib/plugins/liblorelei.so I understand it asks for more, but we really need to make lorelei as simple to use as possible, without pushing the internal details to users. What do you think about this? > Because the plugin is not upstream yet, Lorelei currently builds and tests > against the QEMU fork that carries it. > > The plugin stays deliberately minimal and prescribes nothing about how > thunking is done. Lorelei is one reference implementation of the userspace > side. Any toolchain, or another instrumentation framework, can implement the > same dlcall interface. > > A from-scratch walkthrough of the bare mechanism, with the minizip and > OpenGL/X11 examples above, is also available here: > > https://github.com/rover2024/qemu-passthrough-test > > It is fully opt-in (loaded with -plugin) and targets linux-user, where the > guest and host already share a trust domain. The test cases use x86_64 guests > and run on x86_64, arm64 and riscv64 Linux hosts. > > I have deliberately kept Lorelei out of the patch itself: neither the code > nor its comments mention it, since I am not sure whether referencing an > external project from the tree is welcome. I would appreciate guidance on > where a pointer to the toolchain belongs, if anywhere. For example, would it > be appropriate to mention it from the documentation patch? > > Feedback on the plugin and on the pass-through approach is welcome. > > Changes since v3: > > * Lorelei, the userspace toolchain that implements this interface, is now a > public, documented, CI-tested project, with a Thunk Library Compiler that > generates the guest/host thunks automatically. This addresses the v3 > feedback that the interface needs a public implementation behind it. The > plugin code itself is unchanged. > * The documentation patch is held back for now. > > Changes since v2: > > * Dropped the RFC tag. The approach was positively received on v2. > * Rebased on master and adjusted the syscall-filter callback to its updated > signature (int64_t sysret, added userdata, dropped the plugin id > argument). > > Changes since v1: > > * Renamed the plugin from "passthrough" to "dlcall" (Pierrick Bouvier). > The old name was too generic. The name "dlcall" reflects what the plugin actually > does (dlopen/dlsym a host symbol and call it) and avoids confusion with > QEMU's existing plugin hostcall concept (QEMU_PLUGIN_*_HOSTCALL). > * Made the magic syscall number configurable at load time via the > "syscall_num=N" argument, defaulting to 4096 and rejecting values low > enough to clash with a real syscall (Pierrick Bouvier). > > v1: https://lore.kernel.org/qemu-devel/20260617130742.769234-1-functioner@sjtu.edu.cn/ > v2: https://lore.kernel.org/qemu-devel/20260619045404.820960-1-functioner@sjtu.edu.cn/ > v3: https://lore.kernel.org/qemu-devel/20260622163438.130746-1-functioner@sjtu.edu.cn/ > > Thanks, > Ziyang Zhang > > Ziyang Zhang (1): > contrib/plugins: add a minimal dlcall plugin > > contrib/plugins/dlcall.c | 238 ++++++++++++++++++++++++++++++++++++ > contrib/plugins/meson.build | 5 + > 2 files changed, 243 insertions(+) > create mode 100644 contrib/plugins/dlcall.c > Thanks, Pierrick
Hi Pierrick,
Thanks for the review, and for thinking about the end-user experience.
On Tue, 30 Jun 2026 12:34:59 -0700, Pierrick Bouvier wrote:
> Thanks for publishing it.
>
> A few ideas to make Lorelei even more easy to use:
>
> Would that be possible to add binary artifacts to the existing 1.0.0
> Lorelei release?
> Ideally, it should provide a toolchain (for x64 hosts) with support for
> x64, arm64 and riscv64 guest thunks.
>
> Also, would that possible to provide a script to generate boilerplate
> for thunks, and extract list of symbols from a given library?
>
> My ultimate goal would be to have something as simple as:
> $ wget toolchain.hostx64.tar.gz
>
> # automatically generate boilerplate + compile guest/host thunks
> $ toolchain.hostx64/bin/generate-thunks \
> --arch arm64 --library /usr/lib/libfoo.so \
> --header /usr/include/foo.h --out thunks_arm64
>
> $ aarch64-linux-gnu-gcc main.c -lfoo
> $ env LD_LIBRARY_PATH=./thunks_arm64 \
> qemu-arm64 ./a.out -plugin contrib/plugins/liblorelei.so
>
> I understand it asks for more, but we really need to make lorelei as
> simple to use as possible, without pushing the internal details to users.
>
> What do you think about this?
Prebuilt toolchain / instant acceleration
Agreed: the goal is to install it and feel the speedup right away,
with no build step. I'll do this, but as a point release on top of
1.0.0.0 rather than in the initial tag, so it lands as its own
increment. The model is FEX's FEXFetchRootFS: a prebuilt host
toolchain plus ready-made thunks, so a user goes from download
straight to an accelerated guest. Like FEXFetchRootFS, the tool will
likely have the user pick their distribution and version, because a
thunk is bound to a specific library build: the exported symbols, and
sometimes the ABI, differ across distros and releases, so the prebuilt
thunks must match the host's real libraries.
Generating thunks for a new library
One caveat on the generate-thunks sketch. Lorelei guarantees that
thunk *generation* is automatic and reproducible: once a library is
described, TLC deterministically emits both sides, including the
callback and variadic cases. What it cannot do on its own is
*describe* the library, that is, pick the symbols you need and write
descriptors for the ones that do not marshal trivially (callbacks by
pointer, ownership crossing the boundary). Those stay judgment calls
that need a human, or an AI, in the loop.
So adding a new library is not one fully automatic command. What
Lorelei does is drastically cut the effort versus hand-writing every
thunk the way Box64 does: the generate-thunks helper automates what
is automatable (symbol extraction, boilerplate, building both sides),
so simple libraries are close to one-shot and harder ones start from
a skeleton rather than a blank file.
Plugin name
I would rather keep "dlcall" than rename it to "lorelei". The plugin
defines a general interface (the magic-syscall dlopen/dlsym/invoke
ABI), and Lorelei is only one userspace implementation of it now:
- "dlcall" says what the plugin does and is understood without
leaving the tree. "lorelei" names an external project and says
nothing about the mechanism.
- An in-tree interface should not be tied to the branding or
lifetime of an out-of-tree project. If Lorelei is renamed,
forked, or joined by other toolchains, the name becomes
misleading.
- Naming it after one implementation implies it is the blessed one
and discourages alternatives. A generic name keeps QEMU neutral.
- It also matches how the other contrib plugins are named, by
functionality (lockstep, cache, ...).
I do agree Lorelei should be discoverable from the tree, so I'll add
docs to docs/about/emulation.rst that introduce the dlcall interface
and point at Lorelei as a ready-to-use implementation, with a minimal
example and without the internal details.
Does that sound reasonable?
Thanks,
Ziyang Zhang
On 6/30/2026 6:48 PM, Ziyang Zhang wrote: > Hi Pierrick, > > Thanks for the review, and for thinking about the end-user experience. > > On Tue, 30 Jun 2026 12:34:59 -0700, Pierrick Bouvier wrote: >> Thanks for publishing it. >> >> A few ideas to make Lorelei even more easy to use: >> >> Would that be possible to add binary artifacts to the existing 1.0.0 >> Lorelei release? >> Ideally, it should provide a toolchain (for x64 hosts) with support for >> x64, arm64 and riscv64 guest thunks. >> >> Also, would that possible to provide a script to generate boilerplate >> for thunks, and extract list of symbols from a given library? >> >> My ultimate goal would be to have something as simple as: >> $ wget toolchain.hostx64.tar.gz >> >> # automatically generate boilerplate + compile guest/host thunks >> $ toolchain.hostx64/bin/generate-thunks \ >> --arch arm64 --library /usr/lib/libfoo.so \ >> --header /usr/include/foo.h --out thunks_arm64 >> >> $ aarch64-linux-gnu-gcc main.c -lfoo >> $ env LD_LIBRARY_PATH=./thunks_arm64 \ >> qemu-arm64 ./a.out -plugin contrib/plugins/liblorelei.so >> >> I understand it asks for more, but we really need to make lorelei as >> simple to use as possible, without pushing the internal details to users. >> >> What do you think about this? > > > Prebuilt toolchain / instant acceleration > > Agreed: the goal is to install it and feel the speedup right away, > with no build step. I'll do this, but as a point release on top of > 1.0.0.0 rather than in the initial tag, so it lands as its own > increment. The model is FEX's FEXFetchRootFS: a prebuilt host > toolchain plus ready-made thunks, so a user goes from download > straight to an accelerated guest. Like FEXFetchRootFS, the tool will > likely have the user pick their distribution and version, because a > thunk is bound to a specific library build: the exported symbols, and > sometimes the ABI, differ across distros and releases, so the prebuilt > thunks must match the host's real libraries. > > Generating thunks for a new library > > One caveat on the generate-thunks sketch. Lorelei guarantees that > thunk *generation* is automatic and reproducible: once a library is > described, TLC deterministically emits both sides, including the > callback and variadic cases. What it cannot do on its own is > *describe* the library, that is, pick the symbols you need and write > descriptors for the ones that do not marshal trivially (callbacks by > pointer, ownership crossing the boundary). Those stay judgment calls > that need a human, or an AI, in the loop. > > So adding a new library is not one fully automatic command. What > Lorelei does is drastically cut the effort versus hand-writing every > thunk the way Box64 does: the generate-thunks helper automates what > is automatable (symbol extraction, boilerplate, building both sides), > so simple libraries are close to one-shot and harder ones start from > a skeleton rather than a blank file. > > Plugin name > > I would rather keep "dlcall" than rename it to "lorelei". The plugin > defines a general interface (the magic-syscall dlopen/dlsym/invoke > ABI), and Lorelei is only one userspace implementation of it now: > > - "dlcall" says what the plugin does and is understood without > leaving the tree. "lorelei" names an external project and says > nothing about the mechanism. > - An in-tree interface should not be tied to the branding or > lifetime of an out-of-tree project. If Lorelei is renamed, > forked, or joined by other toolchains, the name becomes > misleading. > - Naming it after one implementation implies it is the blessed one > and discourages alternatives. A generic name keeps QEMU neutral. > - It also matches how the other contrib plugins are named, by > functionality (lockstep, cache, ...). > I agree with your arguments, let's keep this name then. > I do agree Lorelei should be discoverable from the tree, so I'll add > docs to docs/about/emulation.rst that introduce the dlcall interface > and point at Lorelei as a ready-to-use implementation, with a minimal > example and without the internal details. > > Does that sound reasonable? > Yes sounds good to me! > Thanks, > Ziyang Zhang > > Thanks, Pierrick
Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes: > On 6/30/2026 6:48 PM, Ziyang Zhang wrote: >> Hi Pierrick, >> >> Thanks for the review, and for thinking about the end-user experience. >> >> On Tue, 30 Jun 2026 12:34:59 -0700, Pierrick Bouvier wrote: >>> Thanks for publishing it. >>> >>> A few ideas to make Lorelei even more easy to use: >>> >>> Would that be possible to add binary artifacts to the existing 1.0.0 >>> Lorelei release? >>> Ideally, it should provide a toolchain (for x64 hosts) with support for >>> x64, arm64 and riscv64 guest thunks. >>> >>> Also, would that possible to provide a script to generate boilerplate >>> for thunks, and extract list of symbols from a given library? >>> >>> My ultimate goal would be to have something as simple as: >>> $ wget toolchain.hostx64.tar.gz >>> >>> # automatically generate boilerplate + compile guest/host thunks >>> $ toolchain.hostx64/bin/generate-thunks \ >>> --arch arm64 --library /usr/lib/libfoo.so \ >>> --header /usr/include/foo.h --out thunks_arm64 >>> >>> $ aarch64-linux-gnu-gcc main.c -lfoo >>> $ env LD_LIBRARY_PATH=./thunks_arm64 \ >>> qemu-arm64 ./a.out -plugin contrib/plugins/liblorelei.so >>> >>> I understand it asks for more, but we really need to make lorelei as >>> simple to use as possible, without pushing the internal details to users. >>> >>> What do you think about this? >> >> >> Prebuilt toolchain / instant acceleration >> >> Agreed: the goal is to install it and feel the speedup right away, >> with no build step. I'll do this, but as a point release on top of >> 1.0.0.0 rather than in the initial tag, so it lands as its own >> increment. The model is FEX's FEXFetchRootFS: a prebuilt host >> toolchain plus ready-made thunks, so a user goes from download >> straight to an accelerated guest. Like FEXFetchRootFS, the tool will >> likely have the user pick their distribution and version, because a >> thunk is bound to a specific library build: the exported symbols, and >> sometimes the ABI, differ across distros and releases, so the prebuilt >> thunks must match the host's real libraries. >> >> Generating thunks for a new library >> >> One caveat on the generate-thunks sketch. Lorelei guarantees that >> thunk *generation* is automatic and reproducible: once a library is >> described, TLC deterministically emits both sides, including the >> callback and variadic cases. What it cannot do on its own is >> *describe* the library, that is, pick the symbols you need and write >> descriptors for the ones that do not marshal trivially (callbacks by >> pointer, ownership crossing the boundary). Those stay judgment calls >> that need a human, or an AI, in the loop. >> >> So adding a new library is not one fully automatic command. What >> Lorelei does is drastically cut the effort versus hand-writing every >> thunk the way Box64 does: the generate-thunks helper automates what >> is automatable (symbol extraction, boilerplate, building both sides), >> so simple libraries are close to one-shot and harder ones start from >> a skeleton rather than a blank file. >> >> Plugin name >> >> I would rather keep "dlcall" than rename it to "lorelei". The plugin >> defines a general interface (the magic-syscall dlopen/dlsym/invoke >> ABI), and Lorelei is only one userspace implementation of it now: >> >> - "dlcall" says what the plugin does and is understood without >> leaving the tree. "lorelei" names an external project and says >> nothing about the mechanism. >> - An in-tree interface should not be tied to the branding or >> lifetime of an out-of-tree project. If Lorelei is renamed, >> forked, or joined by other toolchains, the name becomes >> misleading. >> - Naming it after one implementation implies it is the blessed one >> and discourages alternatives. A generic name keeps QEMU neutral. >> - It also matches how the other contrib plugins are named, by >> functionality (lockstep, cache, ...). >> > > I agree with your arguments, let's keep this name then. > >> I do agree Lorelei should be discoverable from the tree, so I'll add >> docs to docs/about/emulation.rst that introduce the dlcall interface >> and point at Lorelei as a ready-to-use implementation, with a minimal >> example and without the internal details. >> >> Does that sound reasonable? >> > > Yes sounds good to me! Sounds good to me as well ;-) -- Alex Bennée Virtualisation Tech Lead @ Linaro
© 2016 - 2026 Red Hat, Inc.