On Fri, May 22, 2026 at 06:19:16PM -0700, Pierrick Bouvier wrote: > On 5/22/2026 5:40 PM, Warner Losh wrote: > > > > > > On Fri, May 22, 2026 at 6:04 PM Pierrick Bouvier > > <[email protected] > > <mailto:[email protected]>> wrote: > > > > On 5/18/2026 2:27 PM, Warner Losh wrote: > > > Upstream the file, thread, socket and remaining signal system > > calls (too > > > numerous to list here). > > > > > > This series is an ambitous use of claude to help me upstream all the > > > remaining system calls. I've batched them together in what I think are > > > reasonable chunks, and had claude do the grunt work of copying the > > code > > > over and attributing the commits from our complex branching > > history. The > > > chopping up was a bit arbitrary, but I think it's good. The commit > > > messages may be a little weak, but may also be OK. I've also double > > > checked the style and made fixes upstream for them as well. Claude > > also > > > reviewed all these changes and found a few bugs that I've fixed. I've > > > personally read through them all and haven't found anything glaring. I > > > fixed all the bugs that were found, in most cases differently than > > > claude's suggestions. > > > > > > I've added 'Assisted-by: Claude...' to all these commits to reflect my > > > leaning on Claude so hard. This use falls within the 'non- > > creative' use > > > that the Qemu project has said is OK. If that's not the right thing to > > > do, I can remove them. > > > > > > This leaves sysctl translation, the powerpc architecture support, > > > coredumps and a transition to 'truss' based system call tracing. With > > > these changes applied we'er down from a high of about 30k lines of > > diffs > > > to only 5k (not counting genereted, but checked in files in > > blitz). The > > > changes are 8k, so maybe a bit ambitious from that perspective as > > well. > > > > > > There's a few lines over 80 that I've not cleaned up. Let me know if > > > that's a problem. The other warnings are about adding files, and > > there's > > > no new MAINTAINERS entry needed. And the 'arch dependent defines > > should > > > be avoided' are needed to cope with different FreeBSD build systems > > > having different system calls. > > > > > > Note, this is called out below too, but in v2 I've folded back all the > > > fixes based on some out-of-band feedback I recieved to do this the > > > normal way and the qemu project isn't interested in the fixes to > > fixes. > > > > > > This is a big experiment, in many ways, for me, so I'm interested in > > > whatever feedback you may have to make things better in the future. > > > > > > Signed-off-by: Warner Losh <[email protected] <mailto:[email protected]>>
snip > > After reviewing (what I can) two thirds of the series, I don't feel very > > at ease with validating the rest. Not that there is problem in itself, > > but it's a massive add, and I'm not sure how we can ensure it's > > implemented correctly without any test exercising it. > > It's not particular to bsd-user, linux-user does not have test for all > > syscalls implemented neither. > > > > > > Yes. I'd like a low-level test like that. The upstream bsd-user has been too > > incomplete to run real programs prior to this series. And there's still some > > issues that remain after these system calls (which is next up on my list: I > > think elfload needs some patches for PIE). snip > In the real world, seems like we don't really have another option than > taking it, except if you're ready to spend 6 months to add tests for > this series. I'll let other reviewers finish the work for this series. > > I'm not against the pragmatic approach of taking it, and let it be > tested on the field. It would be unfair considering how the rest of QEMU > is not always tested. Yep, as a general rule we have no requirement for formal functional tests for contributions to QEMU. The expectation is that the person submitting the code has tested that it does what they claim. Anything beyond that is a "nice to have". Especially for brand new features, we don't need to worry about regressions either. This bsd-user code has had a complex history out of tree, so it is an unusual situation compared to most other contributions we receive. The FreeBSD maintainers have had a long term burden carrying this out of tree for too long but it was actually used, while we've shipped a non-functional version upstream that no one used. In terms of code review we can assume that this is all already peer reviewed by multiple people in the FreeBSD community. So unless someone in QEMU community happens to have specific FreeBSD knowledge, I don't think we really need to review this from a functional correctness POV. The multiple Signed-off-bys already indicate sufficient functional review IMHO. Rather my expectation for merge is that we're doing more of a "sanity check" that the patches are something that looks reasonable to accept, following the normal QEMU coding practices/styles/etc. Some formal in tree tests would be nice, but I'd say we should focus on getting the current out of tree backlog merged, and worry about tests later once the burden of merging the backlog is eliminated. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
