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 <imp@bsdimp.com>
---
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(-)

diff --git a/bsd-user/meson.build b/bsd-user/meson.build
index 00428fc2f8..c19b1f37a7 100644
--- a/bsd-user/meson.build
+++ b/bsd-user/meson.build
@@ -17,6 +17,7 @@ bsd_user_ss.add(files(
   'plugin-api.c',
   'signal.c',
   'strace.c',
+  '../common-user/thunk.c',
   'uaccess.c',
 ))
 
diff --git a/linux-user/thunk.c b/common-user/thunk.c
similarity index 100%
rename from linux-user/thunk.c
rename to common-user/thunk.c
diff --git a/linux-user/meson.build b/linux-user/meson.build
index 332847a621..f98b4a62cc 100644
--- a/linux-user/meson.build
+++ b/linux-user/meson.build
@@ -17,7 +17,7 @@ linux_user_ss.add(files(
   'signal.c',
   'strace.c',
   'syscall.c',
-  'thunk.c',
+  '../common-user/thunk.c',
   'uaccess.c',
   'uname.c',
 ))

---
base-commit: 769a37d8bd0c81c39128fc292352f01bad0769f4
change-id: 20260312-share-thunk-ab1585477999

Best regards,
-- 
Warner Losh <imp@bsdimp.com>

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 <imp@bsdimp.com>
> ---
> 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.

Regards,
Pierrick

On Thu, Mar 12, 2026 at 11:52 AM Pierrick Bouvier <
pierrick.bouvier@linaro.org> 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 <imp@bsdimp.com>
> > ---
> > 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.

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.

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.

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

Warner

On 3/12/26 1:19 PM, Warner Losh wrote:
> 
> 
> On Thu, Mar 12, 2026 at 11:52 AM Pierrick Bouvier 
> <pierrick.bouvier@linaro.org <mailto:pierrick.bouvier@linaro.org>> 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 <imp@bsdimp.com <mailto:imp@bsdimp.com>>
>      > ---
>      > 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

On Thu, Mar 12, 2026 at 4:36 PM Pierrick Bouvier <
pierrick.bouvier@linaro.org> wrote:

> On 3/12/26 1:19 PM, Warner Losh wrote:
> >
> >
> > On Thu, Mar 12, 2026 at 11:52 AM Pierrick Bouvier
> > <pierrick.bouvier@linaro.org <mailto:pierrick.bouvier@linaro.org>>
> 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 <imp@bsdimp.com <mailto:imp@bsdimp.com
> >>
> >      > ---
> >      > 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.
>

Yup, if it were frictionless to duplicated, I'd just do that. But there's
always
some hassle or another that comes from it. And it's a dependency on doing
the ioctl round of upstreaming.


> > 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.
>

Yea. I'm looking for a reasonable tradeoff. I'm open to suggestions, and am
even willing to split things up: "now the hack, I'll remove it within a
year" sort
of thing just to get this years-long process of upstreaming done.


> > 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.
>

Yea. You should have seen the pushback I got from changing the copyright
header when I had the permissions to do it....  If I copy the file, it's a
full copy, verbatim, no changes. It's not my code, so I can't change
things.  I have a similar issue from some code I plan on copying from
FreeBSD to avoid having to chase the strace.list stuff. Since I can easily
hack upstream FreeBSD to be what I need for qemu, I'll evolve things there
(ideally, just making it a private library I can hook into the bsd-user
build for tracing so qemu gets whatever FreeBSD does in truss for free...

But maybe the next round is all but the ioclts and see if some other
solution can be found in the interim.

Or maybe I'll find the right people that can sign off on 'just copy it' so
I can get on with things :)


> As you said, pick up the right battles and ignore the rest.
>

Yea. Maybe the next round will just be the simple stuff w/o battles....


> > Warner
>
> Regards,
> Pierrick
>

On 3/12/26 4:17 PM, Warner Losh wrote:
> 
> 
> On Thu, Mar 12, 2026 at 4:36 PM Pierrick Bouvier 
> <pierrick.bouvier@linaro.org <mailto:pierrick.bouvier@linaro.org>> wrote:
> 
>     On 3/12/26 1:19 PM, Warner Losh wrote:
>      >
>      >
>      > On Thu, Mar 12, 2026 at 11:52 AM Pierrick Bouvier
>      > <pierrick.bouvier@linaro.org <mailto:pierrick.bouvier@linaro.org>
>     <mailto:pierrick.bouvier@linaro.org
>     <mailto:pierrick.bouvier@linaro.org>>> 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 <imp@bsdimp.com
>     <mailto:imp@bsdimp.com> <mailto:imp@bsdimp.com <mailto:imp@bsdimp.com>>>
>      >      > ---
>      >      > 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.
> 
> 
> Yup, if it were frictionless to duplicated, I'd just do that. But 
> there's always
> some hassle or another that comes from it. And it's a dependency on doing
> the ioctl round of upstreaming.
>
>      > 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.
> 
> 
> Yea. I'm looking for a reasonable tradeoff. I'm open to suggestions, and am
> even willing to split things up: "now the hack, I'll remove it within a 
> year" sort
> of thing just to get this years-long process of upstreaming done.
>

As mentioned, I think that extracting common part in a file and put the 
rest in thunk-target.h is the best approach here.

If creating a new file creates too much frustration, I would be happy to 
give you a reviewed-by on simply moving all functions as static inline 
ones in thunk-target.h.

And if even this is still too complicated, I would be happy to give a 
reviewed-by on any copyright change for this file.

You have now 3 solutions without any hack :)

>      > 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.
> 
> 
> Yea. You should have seen the pushback I got from changing the copyright 
> header when I had the permissions to do it....  If I copy the file, it's 
> a full copy, verbatim, no changes. It's not my code, so I can't change 
> things.  I have a similar issue from some code I plan on copying from 
> FreeBSD to avoid having to chase the strace.list stuff. Since I can 
> easily hack upstream FreeBSD to be what I need for qemu, I'll evolve 
> things there (ideally, just making it a private library I can hook into 
> the bsd-user build for tracing so qemu gets whatever FreeBSD does in 
> truss for free...
>

I indeed read this thread, which was pointed to me by other people who 
read it also. Our general opinion was that it's totally unfair to push 
all this on you, and that idealism on license comments is absolutely not 
worth all the hassle, especially for someone trying to help on his free 
time. Even for someone paid to do it, it would not be worth.

I ran as well into issues of pragmatism vs idealism with the concerned 
person on this thread, and there is alas no proper solution to end this 
behavior. The simplest way to deal with it is to stick to rationale 
arguments, not let it go and don't apologize for saying "No, it's 
unreasonable to ask for this".
If enough people do this, it might end up triggering a positive change 
in the community, instead of implicitely validating this behavior 
blocking contributions.

For concerned bsd-user files, and using a rationale approach, I would 
simply suggest to contact past contributors of those files to collect a 
OK, or ideally ask them to answer on this thread and mention "I'm ok". 
If they don't answer after one week, consider it's an implicit ok. Then 
move on, and pull the changes. No one will come sue you or QEMU for a 
copyright comment.

> But maybe the next round is all but the ioclts and see if some other 
> solution can be found in the interim.
> 
> Or maybe I'll find the right people that can sign off on 'just copy it' 
> so I can get on with things :)
> 
>     As you said, pick up the right battles and ignore the rest.
> 
> 
> Yea. Maybe the next round will just be the simple stuff w/o battles....
> 
>      > Warner
> 
>     Regards,
>     Pierrick
> 

Thanks for all the work you're doing on bsd side, this part really needs 
some love, and it's really good to see someone giving it.

Regards,
Pierrick

On Thu, Mar 12, 2026 at 5:50 PM Pierrick Bouvier <
pierrick.bouvier@linaro.org> wrote:

> On 3/12/26 4:17 PM, Warner Losh wrote:
> >
> >
> > On Thu, Mar 12, 2026 at 4:36 PM Pierrick Bouvier
> > <pierrick.bouvier@linaro.org <mailto:pierrick.bouvier@linaro.org>>
> wrote:
> >
> >     On 3/12/26 1:19 PM, Warner Losh wrote:
> >      >
> >      >
> >      > On Thu, Mar 12, 2026 at 11:52 AM Pierrick Bouvier
> >      > <pierrick.bouvier@linaro.org <mailto:pierrick.bouvier@linaro.org>
> >     <mailto:pierrick.bouvier@linaro.org
> >     <mailto:pierrick.bouvier@linaro.org>>> 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 <imp@bsdimp.com
> >     <mailto:imp@bsdimp.com> <mailto:imp@bsdimp.com <mailto:
> imp@bsdimp.com>>>
> >      >      > ---
> >      >      > 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.
> >
> >
> > Yup, if it were frictionless to duplicated, I'd just do that. But
> > there's always
> > some hassle or another that comes from it. And it's a dependency on doing
> > the ioctl round of upstreaming.
> >
> >      > 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.
> >
> >
> > Yea. I'm looking for a reasonable tradeoff. I'm open to suggestions, and
> am
> > even willing to split things up: "now the hack, I'll remove it within a
> > year" sort
> > of thing just to get this years-long process of upstreaming done.
> >
>
> As mentioned, I think that extracting common part in a file and put the
> rest in thunk-target.h is the best approach here.
>
> If creating a new file creates too much frustration, I would be happy to
> give you a reviewed-by on simply moving all functions as static inline
> ones in thunk-target.h.
>
> And if even this is still too complicated, I would be happy to give a
> reviewed-by on any copyright change for this file.
>
> You have now 3 solutions without any hack :)
>

Great! I'll give it another run. My earlier attempts were in the inbetween
spaces of my day.

Moving to a new file isn't so bad. That seems to be fine to regularize the
copyright stuff. I'll give that a try and see if I can find the right way
to refactor that's not obnoxious.... and doesn't break anything...


> >      > 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.
> >
> >
> > Yea. You should have seen the pushback I got from changing the copyright
> > header when I had the permissions to do it....  If I copy the file, it's
> > a full copy, verbatim, no changes. It's not my code, so I can't change
> > things.  I have a similar issue from some code I plan on copying from
> > FreeBSD to avoid having to chase the strace.list stuff. Since I can
> > easily hack upstream FreeBSD to be what I need for qemu, I'll evolve
> > things there (ideally, just making it a private library I can hook into
> > the bsd-user build for tracing so qemu gets whatever FreeBSD does in
> > truss for free...
> >
>
> I indeed read this thread, which was pointed to me by other people who
> read it also. Our general opinion was that it's totally unfair to push
> all this on you, and that idealism on license comments is absolutely not
> worth all the hassle, especially for someone trying to help on his free
> time. Even for someone paid to do it, it would not be worth.
>

Yea. I'm mostly happy to follow the rules, if I know what they are and they
don't cause too much extra work that sidetrack me. I think I have them now,
and pre-did all the copyright header fuzziness that I had permission to do
in bsd-user so the next round shouldn't be so weird.


> I ran as well into issues of pragmatism vs idealism with the concerned
> person on this thread, and there is alas no proper solution to end this
> behavior. The simplest way to deal with it is to stick to rationale
> arguments, not let it go and don't apologize for saying "No, it's
> unreasonable to ask for this".
> If enough people do this, it might end up triggering a positive change
> in the community, instead of implicitely validating this behavior
> blocking contributions.
>
> For concerned bsd-user files, and using a rationale approach, I would
> simply suggest to contact past contributors of those files to collect a
> OK, or ideally ask them to answer on this thread and mention "I'm ok".
> If they don't answer after one week, consider it's an implicit ok. Then
> move on, and pull the changes. No one will come sue you or QEMU for a
> copyright comment.
>

Yea. Sounds fair. I'll have another blast of about 100 patches, and that
should get us down to ioctls and truss needing to be merged, which I hope
to find a novel solution for... Better to merge the stuff w/o known hassles
then do the hassle-ful stuff.  Once I get it all in, my time can go to
making things better again...

Thanks for the help and listening to my concerns.

Warner


> > But maybe the next round is all but the ioclts and see if some other
> > solution can be found in the interim.
> >
> > Or maybe I'll find the right people that can sign off on 'just copy it'
> > so I can get on with things :)
> >
> >     As you said, pick up the right battles and ignore the rest.
> >
> >
> > Yea. Maybe the next round will just be the simple stuff w/o battles....
> >
> >      > Warner
> >
> >     Regards,
> >     Pierrick
> >
>
> Thanks for all the work you're doing on bsd side, this part really needs
> some love, and it's really good to see someone giving it.
>
> Regards,
> Pierrick
>

On Thu, Mar 12, 2026 at 7:11 AM Warner Losh <imp@bsdimp.com> 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 <imp@bsdimp.com>
> ---
> 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.
>

I can also do the #include "../common-user/thunk.c" hack. But this seemed
more straightforward. I'm also open to other ways to share. I can't just
put it
into the common-user/meson.build list since it needs to be per-target, not
for
the host. There doesn't seem to be a generic '*_user_ss' I can use. the
user_ss
that common-user/meson.build users is in addition to bsd_user_ss or
linux_user_ss.

Warner


> ---
>  bsd-user/meson.build                | 1 +
>  {linux-user => common-user}/thunk.c | 0
>  linux-user/meson.build              | 2 +-
>  3 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/bsd-user/meson.build b/bsd-user/meson.build
> index 00428fc2f8..c19b1f37a7 100644
> --- a/bsd-user/meson.build
> +++ b/bsd-user/meson.build
> @@ -17,6 +17,7 @@ bsd_user_ss.add(files(
>    'plugin-api.c',
>    'signal.c',
>    'strace.c',
> +  '../common-user/thunk.c',
>    'uaccess.c',
>  ))
>
> diff --git a/linux-user/thunk.c b/common-user/thunk.c
> similarity index 100%
> rename from linux-user/thunk.c
> rename to common-user/thunk.c
> diff --git a/linux-user/meson.build b/linux-user/meson.build
> index 332847a621..f98b4a62cc 100644
> --- a/linux-user/meson.build
> +++ b/linux-user/meson.build
> @@ -17,7 +17,7 @@ linux_user_ss.add(files(
>    'signal.c',
>    'strace.c',
>    'syscall.c',
> -  'thunk.c',
> +  '../common-user/thunk.c',
>    'uaccess.c',
>    'uname.c',
>  ))
>
> ---
> base-commit: 769a37d8bd0c81c39128fc292352f01bad0769f4
> change-id: 20260312-share-thunk-ab1585477999
>
> Best regards,
> --
> Warner Losh <imp@bsdimp.com>
>
>