From owner-cvs-sys Mon Oct 23 12:07:02 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA18692 for cvs-sys-outgoing; Mon, 23 Oct 1995 12:07:02 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA18662 ; Mon, 23 Oct 1995 12:06:51 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11462; Mon, 23 Oct 1995 11:58:51 -0700 From: Terry Lambert Message-Id: <199510231858.LAA11462@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: swallace@ece.uci.edu (Steven Wallace) Date: Mon, 23 Oct 1995 11:58:50 -0700 (MST) Cc: bde@freefall.freebsd.org, CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@FreeBSD.ORG In-Reply-To: <199510212304.QAA06180@newport.ece.uci.edu> from "Steven Wallace" at Oct 21, 95 04:04:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2702 Sender: owner-cvs-sys@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. Seeing this on -hackers, I'd like to have someone back up and explain "the static function idea", since it seems likely that an alternate approact to the idea might be more fruitful than rewriting the system call interface such that we have to hack tables all over hell for no real gain. > > 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 have macros that divorce K&R and ANSI vararg behaviour from the code itself (I use them for various things myself). Is this what we are trying to accomplish? > > 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! No, this is good -- system calls are a scarce resource and should be consumed conservatively. What's the problem you have with anonymous argument vectors using subfunction codes? > We need a better way to handle these syscall subcodes (as SYSV calls 'em). I guess I don't really understand why these are a problem, unless you are trying to do something silly, like prototype them. > 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). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.