From owner-freebsd-hackers Fri Aug 6 6:54:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xena.mindspring.com (xena.mindspring.com [207.69.142.2]) by hub.freebsd.org (Postfix) with ESMTP id 7659A15156 for ; Fri, 6 Aug 1999 06:54:13 -0700 (PDT) (envelope-from rsanders@xena.mindspring.com) Received: (from rsanders@localhost) by xena.mindspring.com (8.9.3/8.8.5) id JAA29420; Fri, 6 Aug 1999 09:52:14 -0400 (EDT) From: Robert Sanders To: hackers@freebsd.org Subject: Re: Jail syscalls References: <199908041804.LAA31039@apollo.backplane.com> Date: 06 Aug 1999 09:52:14 -0400 In-Reply-To: Matthew Dillon's message of "Wed, 4 Aug 1999 11:04:06 -0700 (PDT)" Message-ID: Lines: 29 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.1 (20 Minutes to Nikko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon writes: > I think we basically have two choices: > > * Pass the sizeof(struct) as part of the system call. Please, not as > part of the structure! That would make this syscall the odd-man-out > compared to all the other syscalls that take size arguments. > > * Make the first field of the structure a real version id, one that is > taken from the same include file that the structure was defined in, > and require that the field be filled in. And, of course, passing the version number as an argument to the syscall*. That has the advantage of not having to initialize the structure version field, not having to worry about incompatible structures of equal size, and not unnecessarily enlarging the structure with version information. Embedded version numbers would win in situations wherein modules compiled with old header files were passing structures to modules that were compiled with new header files, and that such structures were given as arguments to syscalls invoked in the new module. That seems pretty unlikely. regards, -- Robert * The really perverse might suggest that this versioning be hidden from the user via macro/inline procedure trickery. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message