RFC: patch to make d_fileno 64bits

[Kirk McKusick]

> Date: Fri, 21 Nov 2014 17:57:54 +0200
> From: Konstantin Belousov <kostikbel at gmail.com>
> To: Rick Macklem <rmacklem at uoguelph.ca>
> Subject: Re: RFC: patch to make d_fileno 64bits
> 
> I do not think we need to have in-kernel compatibility shims.
> The work, big but relatively trivial, is to convert filesystems to
> use the new ino_t, even if the on-disk structures still use 32bit
> inode number.
> 
> Really problematic part of this change is the usermode ABI breakage.
> The struct dirent is only the start of the whole issue. ino_t is
> embedded into more structures which are part of the contract, e.g.
> struct stat.  We have to provide new syscalls which accept or return
> the affected structures.
> 
> And then, there are libraries which embed ino_t into their ABI.
> Immediate example is fts(3) in libc. Look at the FTSENT.fts_ino. Even
> after the base system is fixed by properly providing the compat shims
> and symbol versions for the affected libraries, we get the same problem
> with the binaries not from base.
> 
> Summary of the issue with ino_t is that it is not too hard to fix the
> kernel, comparing with the ABI issues which must be solved in usermode.

You are quite right that this is a big and complex process. It was
first attempted as a Google Summer of Code project which was later
(in August 2011) integrated in projects/ino64. The hurdle for getting
it in was too high and it has since languished. We discussed the need
to get this done at the MeetBSD developer summit and I agreed to take
a fresh look to see if we could pull it off in time for FreeBSD-11.
I have started looking at resurrecting the work done in projects/ino64
and will work with Rick to come up with a proposal.

As you note, getting a kernel working with backward compatibility is
straight-forward. If you have ideas on how to handle the usermode
ABI issues, they would be most appreciated.

	Kirk McKusick