From owner-freebsd-current@FreeBSD.ORG  Tue May 13 07:08:41 2003
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 E4D9137B401
	for <freebsd-current@freebsd.org>;
	Tue, 13 May 2003 07:08:41 -0700 (PDT)
Received: from britannica.bec.de (kuecklich.e-technik.uni-rostock.de
	[139.30.206.20])	by mx1.FreeBSD.org (Postfix) with SMTP id B08D643FCB
	for <freebsd-current@freebsd.org>;
	Tue, 13 May 2003 07:08:40 -0700 (PDT)
	(envelope-from joerg@britannica.bec.de)
Received: (qmail 12959 invoked by uid 1001); 13 May 2003 14:08:28 -0000
Date: Tue, 13 May 2003 16:08:28 +0200
From: User Joerg <joerg@britannica.bec.de>
To: freebsd-current@freebsd.org
Message-ID: <20030513140828.GA12938@britannica.bec.de>
Mail-Followup-To: freebsd-current@freebsd.org
References: <200305112244.h4BMiFTh036221@beastie.mckusick.com>
	<3EBFB57D.7376D4A8@mindspring.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3EBFB57D.7376D4A8@mindspring.com>
User-Agent: Mutt/1.4.1i
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
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 13 May 2003 14:08:42 -0000

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

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.

You might even drop the kernel support for old versions and just
provide that special shared object especially for statically
compiled apps.

Just my 2 cent.

-- Joerg

> 
> -- Terry