Date: Fri, 27 Oct 1995 16:50:50 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) 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 Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Message-ID: <199510272350.QAA24249@phaeton.artisoft.com> In-Reply-To: <199510272157.HAA29637@godzilla.zeta.org.au> from "Bruce Evans" at Oct 28, 95 07:57:34 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510272350.QAA24249>