RFC: patch to make d_fileno 64bits

[Gleb Kurtsou]

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 */
};

> 
> 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"
> > 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ino64-sys-sys.patch
Type: text/x-diff
Size: 15228 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20141122/8286ef18/attachment.patch>