On Fri, Jun 16, 2017 at 05:01:43PM -0700, Mark Millard wrote: > buildworld via clang for powerpc64 and powerpc fails for lack of > `__udivdi3' referenced in sys/boot/common/ufsread.c fsread_size > code. But this lead to me looking around and I found a conceptually > separate possible issue. . . > > sys/sys/_types.h : > > typedef __uint64_t __ino_t; /* inode number */ > > # find /usr/src/sys/ -exec grep __ino_t {} \; -print | more > typedef __ino_t ino_t; > /usr/src/sys/sys/stat.h > typedef __ino_t ino_t; /* inode number */ > /usr/src/sys/sys/types.h > typedef __uint64_t __ino_t; /* inode number */ > /usr/src/sys/sys/_types.h > typedef __ino_t ino_t; > /usr/src/sys/sys/dirent.h > > > sys/boot/common/ufsread.c : > > . . . > #include <ufs/ufs/dinode.h> > #include <ufs/ufs/dir.h> > #include <ufs/ffs/fs.h> > . . . > typedef uint32_t ufs_ino_t; > . . . > > Note the 32-bit type above. The headers included > have use of the 64-bit ino_t type as well, for > example: > > sys/ufs/ufs/diniode.h : > > . . . > #define UFS_ROOTINO ((ino_t)2) > . . . > #define UFS_WINO ((ino_t)1) > . . . > > sys/ufs/ffs/fs.h : > > . . . > #define ino_to_cg(fs, x) (((ino_t)(x)) / (fs)->fs_ipg) > #define ino_to_fsba(fs, x) \ > ((ufs2_daddr_t)(cgimin(fs, ino_to_cg(fs, (ino_t)(x))) + \ > (blkstofrags((fs), ((((ino_t)(x)) % (fs)->fs_ipg) / INOPB(fs)))))) > #define ino_to_fsbo(fs, x) (((ino_t)(x)) % INOPB(fs)) > . . . > > > I believe the powerpc64/powerpc issue > gives evidence of ino_t being used in > addition ot ufs_ino_t in > sys/boot/common/ufsread.c 's fsread_size . > > > Other things that look 32-bit inode-ish: > (I do not claim to know that any of this > matters.) > > sys/ufs/ufs/dir.h has: > > struct direct { > u_int32_t d_ino; /* inode number of entry */ > . . . > struct dirtemplate { > u_int32_t dot_ino; > . . . > u_int32_t dotdot_ino; > . . . > > struct odirtemplate { > u_int32_t dot_ino; > . . . > u_int32_t dotdot_ino; > . . . > > > sys/ufs/ffs/fs.h has: > > struct jrefrec { > . . . > uint32_t jr_ino; > > struct jmvrec { > . . . > uint32_t jm_ino; > > struct jblkrec { > . . . > uint32_t jb_ino; > > struct jtrncrec { > . . . > uint32_t jt_ino; UFS uses 32bit inodes, changing to 64bit is both pointless currently, and causes on-disk layout incompatibilities. As a consequence, use of ino_t (64bit) or uint32_t for inode numbers are almost always interchangeable, unless used for specifying on-disk layout. UFS correctly uses (and was changed to use) uint32_t for inode numbers in the disk-layout definitions. Other places, which calculate inode numbers from inode block numbers, or do some other calculations with inodes, are fine with either width. That is, I believe that all instances which I looked at during the ino64 preparation are fine.Received on Sat Jun 17 2017 - 00:48:59 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:12 UTC