Date: Sat, 3 Jul 2004 19:09:15 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Tim Robbins <tjr@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: cvs commit: src/sys/conf NOTES files options src/sys/fs/msdosfs msdosfs_fileno.c msdosfs_vfsops.c msdosfs_vnops.c msdosfsmount.h src/sys/modules/msdosfs Makefile Message-ID: <20040704020915.GI95729@elvis.mu.org> In-Reply-To: <20040704004444.GA52008@cat.robbins.dropbear.id.au> References: <200407031322.i63DMdqC084182@repoman.freebsd.org> <20040703230127.GG95729@elvis.mu.org> <20040704004444.GA52008@cat.robbins.dropbear.id.au>
next in thread | previous in thread | raw e-mail | index | archive | help
* Tim Robbins <tjr@freebsd.org> [040703 17:41] wrote: > On Sat, Jul 03, 2004 at 04:01:27PM -0700, Alfred Perlstein wrote: > > What are the implications of expanding the VFS API to take 64bit > > inodes? > > Widening ino_t to 64 bits would change the layout/size of struct stat, so > we'd have to add a new stat() syscall (as well as fstat(), lstat()) and add > compatibility code for binaries that expect the old layout. We'd also have > to sweep through VFS to find the instances where i-numbers are being stored > in wrong types, e.g. struct vattr's va_fileid member uses 'long' instead > of 'ino_t' for some reason. I think it's something that would be best > left until 6-CURRENT. Bah, we can do it. :) -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040704020915.GI95729>