On Sat, 15 Jan 2022 at 06:19, Warner Losh <i...@bsdimp.com> wrote: > I need to work through those things in our development branch before trying > to fold them into this series. And I'm not yet sure the right way to do that > because > many of the things are likely to be largish changes that may be tough to > manage > keeping this patch series in sync. So I'm going to do all the trivial style > and > tiny bug things first, then tackle this more fundamental issue. I've thought > about it enough to understand that the code in this patch series has some > conceptual mistakes that must be addressed. Having this very detailed feedback > is quite helpful in laying out the path for me to fix these issues (even if I > don't > ultimately do everything like linux-user, I'll know why it's different rather > than > the current situation where there's much inherited code and the best answer > I could give is 'well linux-user was like that 5 years ago and we needed to > make > these hacks to make things work' which is completely unsatisfying to give and > to hear.
Mmm. To the extent that the signal handling code you have in your out-of-tree branch is "this is what FreeBSD is shipping to users and it works more-or-less", maybe we should just accept that upstream with (with comments noting that it's got issues/is based on an older linux-user) and then update it to match today's linux-user as a second round of patching? If we have a definite path to eventually getting to the right place, I don't want to insist that you update all this stuff in your branch first before we let it land upstream if that's going to burden you with massively more work. -- PMM
