On 3/12/26 1:19 PM, Warner Losh wrote:
On Thu, Mar 12, 2026 at 11:52 AM Pierrick Bouvier
<[email protected] <mailto:[email protected]>> wrote:
On 3/12/26 6:10 AM, Warner Losh wrote:
> thunk.c is the same between linux-user and bsd-user (out of tree),
> so share it between the two.
>
> Signed-off-by: Warner Losh <[email protected] <mailto:[email protected]>>
> ---
> As part of upstream blitz bsd-user, I've discovered that bsd-user and
> linux-user have the same thunk.c file. Rather than copy it, put
it into
> the common-user directory and share it. It has to be compiled
> per-target, unlike the rest of common-user, so modify linux-user and
> bsd-user to grab it from there.
> ---
> bsd-user/meson.build | 1 +
> {linux-user => common-user}/thunk.c | 0
> linux-user/meson.build | 2 +-
> 3 files changed, 2 insertions(+), 1 deletion(-)
>
Indeed, thunk.c seems to be highly target specific.
A good solution would be to move common functions to common-user/
thunk.c
and the rest in include/user/thunk.h. It may be cleaner than doing the
meson hack. Or leave it duplicated for now, except if you plan on
modifying it.
My concern with leaving it duplicated is the process. I create a patch
to create
bsd-user/thunk.c that's a verbatim copy of linux-user/thunk.c. Despite
putting in
my cover that this is copied code, if past is prologue, then I'll be
asked to fix the
copyright and style, plus lots of suggestions to improve the code. But
it's just a
verbatim copy, so that's a lot of hassle just to copy it.
I understand, and it's a good intention to want to remove this
duplication. However, I'm not convinced a build system hack is better
than a duplication.
Moving like this, though, is almost 0 friction. A small tweak to meson
is all that's
needed. I suppose I could do the #include "../linux-user/trunk.c" trick
to make it
less ugly in the build system, but then it's not clear it's shared, etc
and more ugly
in the code, imho.
Yes, it's a hack, that's what it's for, "quick and that works but not a
proper solution".
I tried to move this stuff into thunk.h as much as possible so we could
have one
compilation, and that didn't work. It really assumes that it can include
qemu.h for
the tswap, etc macros. So it's impossible to just build once.
Yes, not all functions can be compiled once because they have target
dependencies. That's why I invited you to simply extract common
functions to common-user/thunk.c and leave the target specific bits in
thunk.h (with static inline functions), or in a thunk-target.h header if
you really want to do it cleanly. That's the proper solution here.
Build systems and preprocessor are not a shortcut to proper software
architecture, even though QEMU abused both of them to this end.
Now looking at the code, a lot of it would be a lot simpler with
'Generic', but that's
a battle for another day. As is the notion of just generating this data
from the .h files
rather than hard-coding it here, but that too is a battle for another
day. I'd like to
get this upstreamed so I'm spending my time on these sorts of battle.s
I totally get it, and we have been dealing with a lot of things like
this for the single-binary topic, trying to find the good compromises
between refactoring APIs and doing limited changes.
If extracting the common and target part looks like too much work, just
leave it and simply change the copyright header, it's not a big thing to
do, and you can modify both in the same series, no one will yell at you
for changing comments in one file in linux-user.
As you said, pick up the right battles and ignore the rest.
Warner
Regards,
Pierrick
