RFC: patch to make d_fileno 64bits

[Rick Macklem]

Gleb Kurtsou wrote:
> On (21/11/2014 19:33), Rick Macklem wrote:
> > Gleb Kurtsou wrote:
> > > On (21/11/2014 10:25), John Baldwin wrote:
> [...]
> > > > 
> > > > I think this is already done (along with several other changes)
> > > > more fully in
> > > > the projects/ino64 branch in svn?
> > > 
> > > projects/ino64 was created by mdf for merging GSoC commits, and
> > > it
> > > didn't even get half way through.
> > > 
> > > I'm currently working on merging the code to CURRENT. It's been
> > > more
> > > than 2 years, so there is quite some work in there. I intend to
> > > update
> > > the branch as soon as code is ready for review.
> > > 
> > Btw, I just took a quick look and I didn't find any changes to
> > "struct dirent"
> > in projects/ino64, so I think my original assumption that this
> > piece of the
> > puzzle hadn't yet been solved, is correct. (Gleb, if you had
> > changes to
> > "struct dirent" and related fs changes, please let me know.)
> 
> projects/ino64 was created for merging GSoC commits. The branch is
> incomplete to say the least.. There are preparatory changes in there
> only. In case you are interested please refer to
> https://github.com/glk/freebsd-ino64/commits/projects/ino64
> 
> BTW original GSoC branch also changes VOP_READDIR for all file
> systems
> to populate dirent.d_off.
> 
> I've attached the patch for some of the system headers generated by
> git diff -r 531f5069a9b0f61b8ecd08e4ed744cec3b022606 -r
> github/projects/ino64 sys/sys/{_types,dirent,mount,stat}.h >
> ~/ino64-sys-sys.patch
> 
> > 
> > Oh, and thanks to some comments, the new struct dirent has already
> > changed to:
> > 
> > struct dirent {
> >    __uint64_t  d_cookie; /* dir cookie for next dir entry */
> >    __uint64_t  d_fileno;
> >    __uint16_t  d_reclen;
> >    __uint8_t   d_type;
> >    __uint8_t   d_namlen;
> >    __uint8_t   d_pad[4]; /* align d_name to 8 byte boundary */
> >    __uint8_t   d_name[MAXNAMLEN + 1];
> > };
> 
> GSoC'2011 code:
> struct dirent {
> 	ino_t      d_fileno;		/* file number of entry */
> 	off_t      d_off;		/* next entry seek offset */
> 	__uint16_t d_reclen;		/* length of this record */
> 	__uint16_t d_namlen;		/* length of string in d_name */
> 	__uint8_t  d_type; 		/* file type, see below */
> 	__uint8_t  d_unused1;
> 	__uint16_t d_unused2;
> 	char	d_name[MAXNAMLEN + 1];	/* name must be no longer than this */
> };
> 
Hmm. I actually was wondering if d_namlen should go to uint16_t just in case
someone wanted to make MAXNAMLEN > 255 someday. I think your variant is better
than mine.

I'll try and take a look at the git stuff (never done git, but I guess I
can't avoid it forever).

Thanks for the pointer, rick

> > 
> > It was pointed out that C would pad the structure to a multiple of
> > 8 bytes
> > for some arches and without d_pad that would imply d_name wasn't at
> > the end
> > of the structure. (Apparently code somewhere find d_name by
> > subtracting MAXNAMLEN + 1
> > from sizeof(struct dirent) and this fails if d_name isn't at the
> > end. Yuck,
> > but the above fixes it.)
> > 
> > However, the size of d_namlen could become uint16_t, if anyone
> > thinks MAXNAMLEN
> > might want to be greater than 255 someday (long away, since that's
> > another ABI change).
> 
> Somebody has already mentioned it previously so I've bumped it to
> uint16
> back than.
> 
> 
> > 
> > rick
> > 
> > > Besides branch also changes dev_t to 64-bit, bumps MNAMELEN to
> > > 1024
> > > and
> > > has complete ABI compatibility shims (probably except openaudit
> > > which
> > > had
> > > issues).
> > > 
> > > 
> > > _______________________________________________
> > > freebsd-fs at freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> > > To unsubscribe, send any mail to
> > > "freebsd-fs-unsubscribe at freebsd.org"
> > > 
>