From owner-cvs-sys Fri Oct 27 17:00:47 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA00346 for cvs-sys-outgoing; Fri, 27 Oct 1995 17:00:47 -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 RAA00329 ; Fri, 27 Oct 1995 17:00:26 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA24249; Fri, 27 Oct 1995 16:50:51 -0700 From: Terry Lambert Message-Id: <199510272350.QAA24249@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: bde@zeta.org.au (Bruce Evans) Date: Fri, 27 Oct 1995 16:50:50 -0700 (MST) Cc: bde@zeta.org.au, terry@lambert.org, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510272157.HAA29637@godzilla.zeta.org.au> from "Bruce Evans" at Oct 28, 95 07:57:34 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5255 Sender: owner-cvs-sys@freebsd.org Precedence: bulk > >> All #pragmas are unportable. > > >All packing assumptions are unportable. I argue that a #pragma beats > >the __attrib crap because a compiler may ignore it. > > A compiler may exec /usr/games/hack to handle every pragma. gcc used > to do this. It doesn't any more. Stahlman did this to be an ass. > >I don't understand why passing a bogus mode to open when O_CREAT wasn't > >present would be a problem??? > > >That is, why not: > > >> int syscall_entry_open(struct proc *p, void *argp, int *retval) > >> { > >> ARG( char const *, PATH); > >> ARG( int, FLAGS); > >> ARG( promoted_mode_t, MODE); > >> > >> return open(p, retval, PATH, FLAGS, MODE); > >> } > > The last ARG() might cause a fatal trap if the arg doesn't exist. It > might be worth guaranteeing that argp points to a safe place to ARG() > can't trap here. But then the caller might have to do more work to > provide a safe place or recover from the trap. This is currently > handled very efficiently by copyin() recovering from traps if the user > doesn't supply enough args. Hence, my use of the 0 argument on the open in user space in the last posting to provide a valid call on vararg. The open(2) call is not a traditional vararg -- it's a limited one. The "..." in its case means "0 or one argument here" instead of "0 or n arguments here". I don't know of a real vararg system call. > >> SYSCALL_ENTRY(open) > >> { > >> ARG( char const *, PATH); > >> ARG( int, FLAGS); > >> ARG( promoted_mode_t, MODE); > >> > >> return open(p, retval, PATH, FLAGS, MODE); > >> } > > This would require large table of #defines of OFFSETs. I prefer to use > literal offsets. Keep all paths at the same offset, etc. > > >I know the XDR aspects re structure packing are an issue, though since > >you seem to be assuming the same compiler source everywhere (GCC), > > No, the OFFSETs depend on the compiler. I assumed the same endianness > in my example, but endianness changes can be handled by more complicated > ARG() code. Pointer alignment for *(foo_t *) is unlikely to be a problem > because the args are usually laid out so that they can be accessed. Yeah. Only makes sense. Actually, MSC doesn't align stuff correctly. They (Microsoft) pad many things to even alignment boundries, but structure contents themselves are tightly packed. One ABI to consider is WINE. > >I don't see where a packing paragma would be more of an issue than > >any other approach requiring compiler modifications. > > It would take about the same work to machine-generate all the pragmas > and padding as to machine-generate all the offsets, e.g., > > #pragma pack(0) /* or whatever stops all packing */ > struct read_args { > char const *path; > int flags; > char pad1[4]; /* little endian, 4 byte ints, 8 byte regs */ > mode_t mode; > char pad2[6]; > }; That would be better expressed as: > #pragma pack(8) /* quad stack alignment, pointers are quads*/ > struct read_args { > char const *path; > int flags; > mode_t mode; > }; [ ... ] > >I'm glad to see this. I think, though, the rationale for the changes > >still hasn't been clarified. > > `lcall' allow users to trace into syscalls. This can be recovered from > but is ugly. Trap gates don't have this problem. NetBSD and Linux > already use trap gates for their native system calls and we don't want > to be uglier or slower than NetBSD or Linux :-). We need to support > trap gates for emulation anyway. If we change to trap gates then we > should consider changing other parts of the syscall interface. We don't > need to copy NetBSD's or Linux's interface except for emulation. I understand the rationale for considering the changes. I don't understand the rationale for making them. It seems the rationale is "to compete with NetBSD and Linux regarding speed". Is this correct? I personally don't find that compelling (that's not to say that the majority doesn't outweigh me on this -- only that it does not convince me, personally). > >This was my point on the quad crap and reverting the default interfaces > >to POSIX compliance (and double doesn't count unless you can use it > >without a prototype in scope). > > if (lseek(fd, (off_t)foo, SEEK_SET) == (off_t)-1) > perror("lseek"); > > works without a prototype in scope even if off_t is quad or double. But violates POSIX (in the quad case) or the spirit of POSIX (in the double case -- you yourself suggested that this is probably an error in the spec). > >> Consider a 68K compiler that passes the first 2 pointer args (if any) > >> in a0-a1 and the first 2 integer args (if any) in d0-d1 and the other > >> args on the stack. How are you going to push the args in syscall()? > >> Hint: you'll need to know the arg types of all syscalls. > > >That's an evil way to pass arguments, then. 8-(. > > But not stupid :-). OK. I admit it's probably minisculely faster. Is it worth the clutter of the xxx_OFFSET and the xxx_type and the unreadable glue routines to get that miniscule speed "improvement"? Just my opinion, but I think the answer is "no". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.