RFC: patch to make d_fileno 64bits

[Rick Macklem]

Kostik wrote:
> On Sat, Nov 22, 2014 at 09:23:41AM -0800, Kirk McKusick wrote:
> > > Date: Sat, 22 Nov 2014 17:34:27 +0200
> > > From: Konstantin Belousov <kostikbel at gmail.com>
> > > To: Rick Macklem <rmacklem at uoguelph.ca>
> > > Subject: Re: RFC: patch to make d_fileno 64bits
> > > Cc: FreeBSD Filesystems <freebsd-fs at freebsd.org>
> > > 
> > > On Fri, Nov 21, 2014 at 06:45:52PM -0500, Rick Macklem wrote:
> > >> Kostik wrote:
> > >> What about old binaries that do getdirentries(2) and expect the
> > >> old
> > >> structure with 32bit d_fileno or the linux compatibility stuff?
> > >> I suspect that there are some old staticly linked binaries out
> > >> there
> > >> that does/expects the old getdirentries.
> > > 
> > > No, let me restate my position.  There are two places for
> > > backward
> > > compatibility, one is in-kernel binary interface, and another is
> > > applications ,i.e. KBI and ABI.
> > > 
> > > My opinion is that we must provide strict backward ABI
> > > compatibility
> > > to have even right to be called useful OS.  In particular, the
> > > syscalls
> > > like current getdirentries (156 and 196) providing 32-bit
> > > inonums, must
> > > be kept with their current binary contract.  The userspace issues
> > > do
> > > not end there, but this is not the currently discussed item.
> > > 
> > > On the other hand, providing KBI compat for filesystems which
> > > work
> > > right now with 32bit inode numbers, should not be done. I.e., no
> > > VOP_READDIR_32INO(), all filesystems must be converted once.
> > > 
Yes, I did understand that others felt having the 2 VOP_READDIR_XX()
wasn't appropriate and that is fine with me. (I just did it to try and
allow file systems to be converted when someone got around to it.)

What I will probably do for my testing is implement a MNTK_DIRENT64
flag that file systems set when they are converted to generating the
new dirent64. (I'm not sure if this could go into head, since I'm
not sure if it would work for stacked file systems? Maybe the stacked
file system could just set the flag if the flag is set for the underlying fs,
but I'm not sure. Anyhow, the object will be to convert all file systems
so this doesn't need to be in head.)

> > > For syscalls 156 and 196 (and some more), the converter must be
> > > written
> > > in the vfs_syscalls.c which translates the new dirents into old
> > > dirents,
> > > at the level of best efforts.
> > 
> > I believe that we are all in agreement with you on the kernel
> > approach
> > at this point.
> Well, I think this was the Rick patch and proposal to have compat
> ino32
> in kernel.
> 
Yes, I agree to one VOP_READDIR() and a converter (already written)
from new->old in vfs_syscalls.c.

> > 
> > Do we have a way of versioning libc so that we can have the old
> > version
> > that provides the 32-bit version of the syscalls (156 and 196)
> > along
> > with 32-bit higher-level functions like fts and friends and then a
> > new
> > libc version that has the 64-bit version of the syscalls and other
> > higher-level functions?
> 
> We do not need several versions of libc. We support symbol
> versioning,
> i.e. we can have old getdirents symbol which resolves to syscall stub
> for 196, and new getdirents for new syscall.
> 
> It is somewhat convoluted feature, you could look at example in
> sys/kern/sysv_*.c, for instance, freebsd7_shmctl and shmctl. Also
> look at libc/include/compat.h.  For pure usermode compat shims,
> lib/libc/gen/fts-compat.c was already handled one time.
> 
> I promise to write neccessary magic for libc versioning when needed.
> As I explained before, unfortunately the libc is not the final point
> for the userspace compat.
> 
I'll keep plugging away at the dirent structure and am glad you guys are
going to attack the tough userland parts.

Good luck with it, rick