Re: INO64 in head: Does sys/boot/common/ufsread.c need its "typedef uint32_t ufs_ino_t;" replaced?
On 2017-Jun-17, at 3:24 AM, Konstantin Belousovwrote: > On Fri, Jun 16, 2017 at 08:54:10PM -0700, Mark Millard wrote: >> On 2017-Jun-16, at 7:48 PM, Konstantin Belousov >> wrote: >> >>> On Fri, Jun 16, 2017 at 05:01:43PM -0700, Mark Millard wrote: . . . >>> >>> 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. >> >> Thanks for letting me know --and good to know. >> >> I've added a note to the bugzilla report of the failed >> linking of boot1.elf for powerpc and powerpc64 that >> you have indicated that if the __udivdi3 is supplied to >> allow the linking to complete for builds based on clang >> then the result should operate okay for the mix of types. >> (The report is bugzilla 220024 .) > I never said that. Sorry. I apparently read too much of my overall purpose into your reply to what I asked about for if the types needed to be changed in fsread.c . I've reported the "I never said that" in 220024. I've also copied and pasted your original reply for reference. Again: Sorry to have misrepresented you. === Mark Millard markmi at dsl-only.net ___ 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"
Re: INO64 in head: Does sys/boot/common/ufsread.c need its "typedef uint32_t ufs_ino_t;" replaced?
On Fri, Jun 16, 2017 at 08:54:10PM -0700, Mark Millard wrote: > On 2017-Jun-16, at 7:48 PM, Konstantin Belousov > wrote: > > > On Fri, Jun 16, 2017 at 05:01:43PM -0700, Mark Millard wrote: > >> . . . > > > > 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. > > Thanks for letting me know --and good to know. > > I've added a note to the bugzilla report of the failed > linking of boot1.elf for powerpc and powerpc64 that > you have indicated that if the __udivdi3 is supplied to > allow the linking to complete for builds based on clang > then the result should operate okay for the mix of types. > (The report is bugzilla 220024 .) I never said that. ___ 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"
Re: INO64 in head: Does sys/boot/common/ufsread.c need its "typedef uint32_t ufs_ino_t;" replaced?
On 2017-Jun-16, at 7:48 PM, Konstantin Belousov wrote: > On Fri, Jun 16, 2017 at 05:01:43PM -0700, Mark Millard wrote: >> . . . > > 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. Thanks for letting me know --and good to know. I've added a note to the bugzilla report of the failed linking of boot1.elf for powerpc and powerpc64 that you have indicated that if the __udivdi3 is supplied to allow the linking to complete for builds based on clang then the result should operate okay for the mix of types. (The report is bugzilla 220024 .) === Mark Millard markmi at dsl-only.net ___ 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"
Re: INO64 in head: Does sys/boot/common/ufsread.c need its "typedef uint32_t ufs_ino_t;" replaced?
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 > #include > #include > . . . > typedef uint32_tufs_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_tjr_ino; > > struct jmvrec { > . . . > uint32_tjm_ino; > > struct jblkrec { > . . . > uint32_tjb_ino; > > struct jtrncrec { > . . . > uint32_tjt_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"
Re: INO64 in head: Does sys/boot/common/ufsread.c need its "typedef uint32_t ufs_ino_t;" replaced?
Top post of context note: I should have noted up front that: /usr/src/sys/boot/powerpc/boot1.chrp/boot1.c does: #include "ufsread.c" and that is the context of the __udivdi3 use that is rejected at link time when clang is used to buildworld for powerpc or pwoerpc64. My original note might really trace back to boot1.c needing to be different even if ufsread.c stays the same. === Mark Millard markmi at dsl-only.net On 2017-Jun-16, at 5:01 PM, Mark Millardwrote: 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 #include #include . . . typedef uint32_tufs_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_tjr_ino; struct jmvrec { . . . uint32_tjm_ino; struct jblkrec { . . . uint32_tjb_ino; struct jtrncrec { . . . uint32_tjt_ino; === Mark Millard markmi at dsl-only.net ___ 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"
INO64 in head: Does sys/boot/common/ufsread.c need its "typedef uint32_t ufs_ino_t;" replaced?
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 #include #include . . . typedef uint32_tufs_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_tjr_ino; struct jmvrec { . . . uint32_tjm_ino; struct jblkrec { . . . uint32_tjb_ino; struct jtrncrec { . . . uint32_tjt_ino; === Mark Millard markmi at dsl-only.net ___ 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"