From owner-freebsd-arch Thu Feb 28 5:14:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from green.bikeshed.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id DFE9337B402; Thu, 28 Feb 2002 05:14:06 -0800 (PST) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.6/8.11.6) with ESMTP id g1SDE3t50441; Thu, 28 Feb 2002 08:14:04 -0500 (EST) (envelope-from green@green.bikeshed.org) Message-Id: <200202281314.g1SDE3t50441@green.bikeshed.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Bruce Evans Cc: "Brian F. Feldman" , Alfred Perlstein , bde@FreeBSD.org, arch@FreeBSD.org Subject: Re: Do we want the _SYS_SYSPROTO_H_ junk? In-Reply-To: Your message of "Thu, 28 Feb 2002 20:52:35 +1100." <20020228202851.X52134-100000@gamplex.bde.org> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Feb 2002 08:14:03 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans 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 > > int > > open(td, uap) > > struct thread *td; > > register struct open_args /* { > > syscallarg(char *) path; > > syscallarg(int) flags; > > syscallarg(int) mode; > > } */ *uap; > > { > > > > The first part, if ever actually called into existence by sysproto.h not > > being included, would be bogus. Do we want to keep introducing those? > > 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 > 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). > The second pseudo-declaration of the struct in the comment is bogus. I > removed the comment globally when I implemented , 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. > Both versions are really just comments. It can be hard to remember what > is in *uap without them. Automatic checking for the ifdefed version would > just check the consistency of the comments. Wrong comments for simple > things are worse than no comments. > > 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. > 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? -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org <> bfeldman@tislabs.com \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message