On Tue, Feb 1, 2022 at 9:23 AM Kyle Evans wrote: > On Tue, Feb 1, 2022 at 5:14 AM Warner Losh wrote: > > > > This doesn't build on openbsd at the moment, and this could > > should arguably be in bsd-user/*bsd/x86_64 somewhere. Until > > we refactor to support OpenBSD/NetBSD again, drop it here. > > > > Signed-off-by: Warner Losh > > --- > > bsd-user/x86_64/target_arch_cpu.h | 27 ++++++++------------------- > > 1 file changed, 8 insertions(+), 19 deletions(-) > > > > Reviewed-by: Kyle Evans > > As a general comment, I'd like to reach out to the others at some > point and gauge interest/ability to participate, but I definitely > agree that it would be better to drop !FreeBSD for now to simplify > upcoming improvements to the common core. I'm not aware of any other > forks that have tried to maintain bsd-user on their platforms. > I did this exercise about 2 years ago now. Neither NetBSD nor OpenBSD communities were using bsd-user because of its super primitive state. There was one person in NetBSD land who was thinking about updating things, and I pointed them at the bsd-user fork, but then heard nothing more from them. I plan on generally dropping not FreeBSD, but in a way that's easy to add back later. I plan on trying to have a reasonable split where it already exists, but I don't plan on rewriting the current code too much when FreeBSD specific things are noted during the review process (like in the signals series of patches). I do commit in the future to working with others that want to do the heavy lifting of making this work with ${OTHER}BSD, should they show up. There are a few more things in the bsd-user fork that I know are FreeBSD specific that aren't in FreeBSD specific files, and I plan on upstreaming them as is given the risk reshufflings represent. To that end, when I do move things to freebsd/, I've also move the netbsd/openbsd code to their respective directories as well, but since that code has been decaying for some number of years now, it will be at best the least imperfect starting point we can have. I also had a bit of a plan to see if people want to update to ${OTHER}BSD once upstreaming is complete. I worry, a bit, that trying to accomodate them during the upstreaming process will slow down the upstreaming process. However, if someone shows up with code, enthusiasm and a clue, I'm happy to reevaluate. Warner > > diff --git a/bsd-user/x86_64/target_arch_cpu.h > b/bsd-user/x86_64/target_arch_cpu.h > > index 9dc52d5afc4..5be2f02416e 100644 > > --- a/bsd-user/x86_64/target_arch_cpu.h > > +++ b/bsd-user/x86_64/target_arch_cpu.h > > @@ -126,25 +126,14 @@ static inline void target_cpu_loop(CPUX86State > *env) > > switch (trapnr) { > > case EXCP_SYSCALL: > > /* syscall from syscall instruction */ > > - if (bsd_type == target_freebsd) { > > - env->regs[R_EAX] = do_freebsd_syscall(env, > > - env->regs[R_EAX], > > - env->regs[R_EDI], > > - env->regs[R_ESI], > > - env->regs[R_EDX], > > - env->regs[R_ECX], > > - env->regs[8], > > - env->regs[9], 0, > 0); > > - } else { /* if (bsd_type == target_openbsd) */ > > - env->regs[R_EAX] = do_openbsd_syscall(env, > > - env->regs[R_EAX], > > - env->regs[R_EDI], > > - env->regs[R_ESI], > > - env->regs[R_EDX], > > - env->regs[10], > > - env->regs[8], > > - env->regs[9]); > > - } > > + env->regs[R_EAX] = do_freebsd_syscall(env, > > + env->regs[R_EAX], > > + env->regs[R_EDI], > > + env->regs[R_ESI], > > + env->regs[R_EDX], > > + env->regs[R_ECX], > > + env->regs[8], > > + env->regs[9], 0, 0); > > env->eip = env->exception_next_eip; > > if (((abi_ulong)env->regs[R_EAX]) >= (abi_ulong)(-515)) { > > env->regs[R_EAX] = -env->regs[R_EAX]; > > -- > > 2.33.1 > > >