From owner-freebsd-arch Mon Mar 11 19:20:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 327BC37B402 for ; Mon, 11 Mar 2002 19:20:46 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2C3KZi53626; Mon, 11 Mar 2002 22:20:35 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 11 Mar 2002 22:20:35 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Garance A Drosihn Cc: Poul-Henning Kamp , Terry Lambert , Harti Brandt , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Mon, 11 Mar 2002, Garance A Drosihn wrote: > So, as far as userland stat() goes, a 64-bit inode is pretty easy, but I > would like to see us set the stage for the other things we keep talking > about. All of those require a bigger struct-stat, and I can't think of > any pretty way of doing that and also maintaining binary compatibility. > Let us pretend that we "absolutely had to" increase the struct, *and* we > could not break binary compatibility, *and* we would maintain posix > compatibility for anything which was simply recompiled. If we had to do > all three of those, how could we do it? My personal feeling on this is that 5.0 is a good time to "take the leap". We know we need to roll the on-disk data structures to support UFS2, we're changing a number of other APIs (shortly including many of the SysV IPC APIs to properly support 32-bit uids and gids). We're completely replacing the threading mechanism, changing many of the APIs for library cals, we've added support for extended attributes, ACLs, etc. Now is the time. The longer the wait, the harder it gets. :-) As to the migration path: your suggestion sounds fine. I'd be tempted to simplify the approach: (1) Provide compatibility system calls in the style of ofoo() providing the 32-bit versions, and make sure that the compatibility libc (and so on) use those. (2) Modify inode.h to look like what we want it to end up looking like, and define new system calls using the native names (stat(), et al). Avoid providing source structure compatibility where it only serves to cause code to use the wrong types without warnings. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message