Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Oct 1995 11:58:50 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        swallace@ece.uci.edu (Steven Wallace)
Cc:        bde@freefall.freebsd.org, CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@FreeBSD.ORG
Subject:   Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c]
Message-ID:  <199510231858.LAA11462@phaeton.artisoft.com>
In-Reply-To: <199510212304.QAA06180@newport.ece.uci.edu> from "Steven Wallace" at Oct 21, 95 04:04:00 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> >   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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510231858.LAA11462>