On Thu, Mar 12, 2026 at 5:50 PM Pierrick Bouvier < [email protected]> wrote:
> 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 :) > 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 >
