From owner-freebsd-hackers Sat Oct 21 16:04:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA15866 for hackers-outgoing; Sat, 21 Oct 1995 16:04:13 -0700 Received: from meter.eng.uci.edu (root@meter.eng.uci.edu [128.200.85.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA15854 for ; Sat, 21 Oct 1995 16:04:05 -0700 Received: from newport.ece.uci.edu by meter.eng.uci.edu (8.7) id QAA18749; Sat, 21 Oct 1995 16:04:02 -0700 (PDT) Received: from localhost by newport.ece.uci.edu (8.7) id QAA06180; Sat, 21 Oct 1995 16:04:01 -0700 (PDT) Message-Id: <199510212304.QAA06180@newport.ece.uci.edu> To: Bruce Evans cc: CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org Subject: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] In-reply-to: Your message of "Sat, 21 Oct 1995 12:50:02 PDT." <199510211950.MAA10580@freefall.freebsd.org> Date: Sat, 21 Oct 1995 16:04:00 -0700 From: Steven Wallace Sender: owner-hackers@freebsd.org Precedence: bulk > to get it right. First we need to catch up with 4.4lite2, which uses > macros to handle struct padding. Then we need to catch up with NetBSD, I hate that SCARG macro. It makes looking at the code harder to understand. Perhaps if we did something like: read(struct proc *p, void *v, int retval[]) { struct read_args /* { int fd; char *buf; u_int nbyte; } */ *uap = v; int fd = SCARG(uap, fd); char *buf = SCARG(uap, buf); u_int nbyte = SCARG(uap, nbyte); ... } That way we don't have SCARG all over the place, and this would prepare us for your static function idea. > which passes the args correctly (as void *). Then we need to handle > varargs functions and struct padding better. I think all the details > can be hidden in machine-generated functions so that the args structs > and verbose macros to reference them don't have to appear in the core > sources. I agree. I don't like SCARG references all over the place. I take it you are refering to your static inline idea. Why don't we just go for that? Or should we do something like my example in the interim? > semsys() and shmsys() syscall interfaces are BAD because they > multiplex several syscalls that have different types of args. > There was no reason to duplicate this sysv braindamage but now > we're stuck with it. NetBSD has reimplemented the syscalls properly > as separate syscalls #220-231. > I agree. This is yucky! I hereby request a plea of help from all you FreeBSD hackers! We need a better way to handle these syscall subcodes (as SYSV calls 'em). I would not call the NetBSD reimplementation as "proper", but it is nicer than what we got right now. Oh, I agree, for new programs compiled it should use those separate syscalls #220-231, but for compatability, the old syscalls will still have to handle the subcodes, and this would still be nasty if left the same. I have run into the same prob with subcodes implementing the ibcs2 emulation. What we need is a new, automatically generated, method of handling subcodes without a nasy if (code == SYS_xxx) ... One idea I have is to use special case for the number of parms. If it is < 0 then special handling should be taken. case -1: Get code from next parameter. case -2: Get code from next parameter (quad_t). case -3: code = (code >> 8) & 0xff; (for ibcs2 xenix emulation) Then use the function pointer as a pointer to a new sysent, and do it all over again (making sure no recursion). I think this solution makes everything generic, without a penalty in performance for normal syscalls. I would like to hear what you guys think and any other ideas you may have towards a "real" solution (if that is ever possible). Steven