On 3/12/26 4:17 PM, Warner Losh wrote:
On Thu, Mar 12, 2026 at 4:36 PM Pierrick Bouvier
<[email protected] <mailto:[email protected]>> wrote:
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]>
<mailto:[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]> <mailto:[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.
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
