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.
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to