From owner-freebsd-current@FreeBSD.ORG Tue May 13 07:37:16 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8203A37B401 for ; Tue, 13 May 2003 07:37:16 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id B37BD43F3F for ; Tue, 13 May 2003 07:37:15 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0093.cvx21-bradley.dialup.earthlink.net ([209.179.192.93] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Fatz-0001MA-00; Tue, 13 May 2003 07:37:12 -0700 Message-ID: <3EC102B1.98F81C77@mindspring.com> Date: Tue, 13 May 2003 07:35:29 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: User Joerg References: <200305112244.h4BMiFTh036221@beastie.mckusick.com> <20030513140828.GA12938@britannica.bec.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4ab5261de6450c3cd881672df8ea1771c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: freebsd-current@freebsd.org Subject: Re: large ufs2 partitions and 'df' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2003 14:37:16 -0000 User Joerg wrote: > On Mon, May 12, 2003 at 07:53:49AM -0700, Terry Lambert wrote: > > If you're going to change the structure, please put a version > > number as the first field, so that it's never a problem again. > > > [...] > > Why don't you do it the other way around? In my understanding > the problem is kernel <-> user mode compatibility. If the syscall > itself takes the version number, the kernel has the following > possibilities: > - it's the native struct stat -> perfect > - it's a supported older version -> convert / fill only needed fields > - otherwise, return EINVAL or similar I was thinking in terms of the technique I used here: http://people.freebsd.org/~terry/DIFF.LOCKS These are patches that seperate the locking namespace by adding a system ID parameter to prevent coelescing of locks belonging to processes on other systems, and to allow specification of a PID for the remote system. The patches themselves are rather dated vs. -current at this point, but they are pretty self explanatory, if you only look at the top of the patch, and ignore the delayed coelescing that it also adds. The net effect is that I'm able to use a different structure size on the copyin/copyout, based on the argument to the kernel function. > If you now add a special version number 0 to query the stat version > of the kernel, you can add a user level conversion function to > catch those EINVAL cases. This would be necessary for cases like > new userland and old kernel. This function might be loaded via dlopen. I'm much less concerned with preventing someone from calling a kernel function with a newer/older structure than I am with making the code still work when it happens. Particularly an older binary on a newer kernel. The code in the example above is able to maintain its binary backward compatability because the new and old structures can be overlaid, and the expansion area is at the end of the structure, instead of in the middle somewhere, and because it uses the command argument as a sort of version number, in and of itself. Without the complete separation of the command namespace (automatic, in the example), I would have needed a version number there, too. Because of the spare fields in the middle in this case, you will need a version number in the structure to maintain binary backward compatability. Effectively, this makes the version number a key field that indicates usage of the spare fields in the middle. > You might even drop the kernel support for old versions and just > provide that special shared object especially for statically > compiled apps. This would work, if everything were linked shared, and no one cared about binary backward compatability. -- Terry