From owner-freebsd-arch Mon Mar 11 18:58:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 9333337B404; Mon, 11 Mar 2002 18:58:40 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g2C2wcrT037172; Mon, 11 Mar 2002 21:58:38 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <65691.1015791493@critter.freebsd.dk> References: <65691.1015791493@critter.freebsd.dk> Date: Mon, 11 Mar 2002 21:58:37 -0500 To: Poul-Henning Kamp From: Garance A Drosihn Subject: Re: Increasing the size of dev_t and ino_t Cc: Terry Lambert , Harti Brandt , Robert Watson , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) 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 At 9:18 PM +0100 3/10/02, Poul-Henning Kamp wrote: >In message , Garance A Drosihn writes: > > >I also think it is a major enough change that we > >need to spend some time to "ease into" it, which is why > >I'm trying to drum up some support for the idea now. > >There isn't much change for these actually, since they do >require two new syscalls and since very few programs even >think about them. > >This is nowhere as troublesome as off_t was. Hmm. How did freebsd handle that transition? is that where the ostat and nstat structs came from in stat.h? > >As to strategy, I guess we could start by adding two new > >fields to 'struct stat', which would be the 64-bit ones. We > >could truncate the 32-bit value and put that in the current > >fields. Some #define would govern whether a program sees > >st_dev and st_ino as the 32-bit values or the 64-bit values. > >No, we can't change the size of struct stat (binary >compatibility!) Now that I look at our present definition of struct-stat, I see that we do have two spare 64-bit fields. If we were only going to do the 64-bit ino_t, then we can do that without breaking binary compatibility. (as long as we fill in both a 32-bit and a 64-bit value). The struct does not have enough spare room to also go for a 64-bit dev_t, because there are two dev_t values in the struct and we only have one more 64-bit spare area to play with. 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? Suggestion: 1) create a set of new routines. Call them stat64(), lstat64(), and fstat64(). 2) the new routines are exactly the same as the present routines, except that they expect a parameter of type 'struct stat64'. 3) (perhaps) provide duplicates of the present stat-routines, which are called stat32(), lstat64(), and fstat64(). 4) Initially create 'struct stat64' with all the same fields at all the same sizes, but with room to expand those fields to what we want to expand them to. Eg, change: __dev_t st_dev; /* inode's device */ ino_t st_ino; /* inode's number */ __dev_t st_rdev; /* device type */ time_t st_atime; /* time of last access */ long st_atimensec; /* nsec of last access */ to: uint_32 st_dev2; /* reserved */ __dev_t st_dev; /* inode's device */ uint_32 st_ino2; /* reserved */ ino_t st_ino; /* inode's number */ uint_32 st_rdev2; /* reserved */ __dev_t st_rdev; /* device type */ uint_32 st_atime2; /* reserved */ time_t st_atime; /* time of last access */ long st_atimensec; /* nsec of last access */ 5) via the magic of #define's, or maybe some loader tricks, have it so anything which is re-compiled will call these new routines instead of the present stat routines. They will obtain a larger stat area, but they won't need to make any other changes because none of the variables have a new type. (or if they *had* to have the smaller struct, they could call the stat32 routines) 6) over time, update the system to fill in the 64-bit versions of all those values. "old" programs will continue to use only the lower-order 32-bits of the newer 64-bit versions, but that should be good enough for most programs. If you think about the above for awhile, and you think about the new 64-bit architectures we are bringing up, then perhaps we could avoid some of these steps for the new ports. Just start out with a struct-stat which includes those extra fields for expansion. It is because of these new ports coming online that I want to think about this right now, and see what we could do before 5.0-release. If we can do some of this work now, we won't have binary-compatibility issues with FreeBSD/sparc64, FreeBSD/ppc, or FreeBSD/ia64. If we wait until after 5.0-release, then we do have that issue. Is the above too ugly to consider doing? I don't think it would be too much work to do (at least to get up to step 4). -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message