From owner-freebsd-current@FreeBSD.ORG Mon Jun 6 16:12:30 2005 Return-Path: X-Original-To: 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 2A6CE16A41C; Mon, 6 Jun 2005 16:12:30 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9907543D48; Mon, 6 Jun 2005 16:12:27 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.4.249.251] ([206.13.39.129]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j56GIEKV053152; Mon, 6 Jun 2005 10:18:25 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42A475D6.4020906@samsco.org> Date: Mon, 06 Jun 2005 10:12:06 -0600 From: Scott Long User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <82ACAD58-B179-44E2-852F-60F25C0BBBC1@FreeBSD.org> <20050606033145.GA80739@www.portaone.com> <42A3D6CF.2000504@samsco.org> <0A6C1F19-A734-4EC8-BE97-2D000D189968@FreeBSD.org> <42A453B5.3020006@samsco.org> <86oeaj1r2x.fsf@xps.des.no> <42A463EF.5060401@samsco.org> <86fyvvqzil.fsf@xps.des.no> <20050606095117.Q52957@pooker.samsco.org> <863brvqxow.fsf@xps.des.no> In-Reply-To: <863brvqxow.fsf@xps.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: Suleiman Souhlal , Garance A Drosihn , current@freebsd.org, fs@freebsd.org, Scott Long Subject: Re: [PATCH] IFS: Inode FileSystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 06 Jun 2005 16:12:30 -0000 Dag-Erling Smørgrav wrote: > Scott Long writes: > >>On Mon, 6 Jun 2005, [iso-8859-1] Dag-Erling Smørgrav wrote: >> >>>Changing the stat(2) API to support 64-bit inodes does not require us >>>to simultaneously change the on-disk layout of every filesystem we >>>support to use 64-bit inodes. However, if we want to fully support >>>filesystems with 64-bit inodes (such as FAT32, which currently uses a >>>convoluted hack to map the 64-bit offset of a directory entry into a >>>32-bit inode), we need to change the API. >> >>Ah, I see your point. Well, it's not too late to address this for 6.0, >>and it might be a really good idea to think about it now. Is there >>anything else that should be bumped along with it? > > > Not that I know of. > > I believe the best way to do this is the way Linux did it: introduce > new *stat64() syscalls and keep the old ones around. #define magic in > will take care of making *stat64() look like *stat(). > > DES So one of the advantages that we have with the 5.x -> 6.0 migration right now is that it's still possible to run a 5.x userland with a 6.x kernel without much problem. Changing fundamental syscalls and structures would defeat this and make life much harder for people that want to sell 6.0 as a painless migration. On the surface I like your idea of stat64 (regardless of politics of having 64-bit specific in the API names), but I'd like to think on it a bit. In the mean time I'm off to listen to Steve profess his love to Intel ;-) Scott