Date: Sun, 3 Mar 2002 22:59:34 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: "Brian F. Feldman" <green@FreeBSD.org> Cc: Alfred Perlstein <bright@mu.org>, <bde@FreeBSD.org>, <arch@FreeBSD.org> Subject: Re: Do we want the _SYS_SYSPROTO_H_ junk? Message-ID: <20020303221043.R65083-100000@gamplex.bde.org> In-Reply-To: <200202281314.g1SDE3t50441@green.bikeshed.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 28 Feb 2002, Brian F. Feldman wrote:
> Bruce Evans <bde@zeta.org.au> wrote:
> > On Wed, 27 Feb 2002, Brian F. Feldman wrote:
> >
> > > I want to know if, on new code, we should put them. E.g.:
> > >
> > > #ifndef _SYS_SYSPROTO_H_
> > > struct open_args {
> > > char *path;
> > > int flags;
> > > int mode;
> > > };
> > > #endif
> > ...
> > The ifdef'ed version is better, if there is to be one at all, because it
> > can at least in theory be checked automatically (e.g., by not including
> > <sys/sysproto.h> so that the struct is not declared, but somehow declare
> > the function anyway; then compile and check if the compile worked and
> > gave the same result).
>
> However, it doesn't _really_ match what's in sys/sysproto.h because it
> doesn't have explicit padding (so could potentially assemble to a different
> format for that object, rather than the one expected by the syscall handler).
Oops. I forgot about the padding. It defeats simple checks like the
above. Putting the padding in MI declarations would be too ugly.
> > The second pseudo-declaration of the struct in the comment is bogus. I
> > removed the comment globally when I implemented <sys/sysproto.h>, but it
> > came back in a few files in the Lite2 merge.
>
> So for documentation's sake, since it really is useful to generally see the
> real "arguments" to a syscall (or vop, or ...) instead of the opaque one, we
> should not have the comment in the declaration itself but keep the one
> before it? I'd definitely prefer to have one.
Yes. I still prefer it separate from the declaration since it gets in the
way less there, but wouldn't change to this style for at least the old vop
functions.
> > The same few files that have syscallarg() in comments also have SCARG()
> > in code. We don't really use either syscallarg() or SCARG(). We just
> > require the MD code to arrange the struct so that ordinary struct member
> > references work right. I would prefer the MD code to push the struct
> > members onto the stack so that no args structs or pseudo-declarations
> > of them are required.
>
> Wouldn't this be not-too-hard to do by declaring an inline function with
> some assembly which would push the argument space onto the stack before
> struct proc * and then calling the sy_call? The only trouble seems to be
> C's general lack of wanting to let you dynamically choose an arbitrary
> amount of data onto the stack, unless there are endianness/object layout
> concerns.
Something like that. I think it needs a function in assembly (or gross
hacks in C) but not an inline function. The function would copy the
syscall args from wherever they are (normally either on a stack in user
space or in an array in the kernel) to wherever they should go (normally
onto a stack) and then call the C entry point. Endianness object layout
concerns potentially need a different function for each syscall.
The only way that I can see to reasonably use inlines is to change all
the current syscall functions to inline ones with prototypes like the
corresponding user interfaces (no args structs). Also change
makesyscalls.sh to generate non-inline functions that call these. E.g.,
the generated lseek() would be something like:
register_t
sys_lseek(struct thread *td, struct open_args *uap)
{
off_t retval;
retval = lseek(uap->fd, uap->offset, uap->whence);
/*
* MD code to assign retval to curthread->td_retval not shown.
*/
return ((register_t)retval); /* Something to not clobber td_retval. */
}
Since lseek() is inline and the above is machine-generated, this is just
as (in)efficient as the current code.
> > I would keep introducing the ifdefed version of the struct while there
> > is still an args struct.
>
> Why, though, do we declare it with the explicit padding in sys/sysproto.h if
> that's just what the machine's compiler will pad it to in the first place?
Because it's not what the compiler will pad it with :-). The padding rules
are different for function parameters.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020303221043.R65083-100000>