Date: Sat, 17 Jun 2017 05:48:50 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Mark Millard <markmi@dsl-only.net> Cc: FreeBSD Current <freebsd-current@freebsd.org>, freebsd-hackers@freebsd.org, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: INO64 in head: Does sys/boot/common/ufsread.c need its "typedef uint32_t ufs_ino_t;" replaced? Message-ID: <20170617024850.GB2088@kib.kiev.ua> In-Reply-To: <3AF2C2DB-1A61-4EC3-BCB7-B05D99273561@dsl-only.net> References: <3AF2C2DB-1A61-4EC3-BCB7-B05D99273561@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170617024850.GB2088>