Date: Sat, 21 Oct 1995 16:04:00 -0700 From: Steven Wallace <swallace@ece.uci.edu> To: Bruce Evans <bde@freefall.freebsd.org> 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] Message-ID: <199510212304.QAA06180@newport.ece.uci.edu> In-Reply-To: Your message of "Sat, 21 Oct 1995 12:50:02 PDT." <199510211950.MAA10580@freefall.freebsd.org>
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.
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510212304.QAA06180>