On Thu, Mar 12, 2026 at 4:36 PM Pierrick Bouvier < [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]>> > 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. > 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 >
