From: Keith Owens <kaos@ocs.com.au>
To: linux-kernel@vger.kernel.org
Subject: daddr_t is inconsistent and barely used
Date: Thu, 16 Aug 2001 12:40:32 +1000 [thread overview]
Message-ID: <9980.997929632@kao2.melbourne.sgi.com> (raw)
daddr_t is barely used in the kernel. 2.4.8.
fs/freevxfs/vxfs.h: daddr_t vsi_oltext; /* OLT extent */
fs/freevxfs/vxfs.h: daddr_t vsi_oltsize; /* OLT size */
fs/freevxfs/vxfs_bmap.c:static daddr_t
fs/freevxfs/vxfs_bmap.c: daddr_t pblock;
fs/freevxfs/vxfs_bmap.c:static daddr_t
fs/freevxfs/vxfs_bmap.c: daddr_t pblock = 0;
fs/freevxfs/vxfs_bmap.c:static daddr_t
fs/freevxfs/vxfs_bmap.c: daddr_t pblock = 0;
fs/freevxfs/vxfs_bmap.c:daddr_t
fs/freevxfs/vxfs_extern.h:extern daddr_t vxfs_bmap1(struct inode *, long);
fs/freevxfs/vxfs_olt.c:vxfs_oblock(daddr_t oblock, u_long bsize)
fs/freevxfs/vxfs_subr.c: daddr_t pblock;
fs/freevxfs/vxfs_subr.c: daddr_t pblock;
include/linux/genhd.h: daddr_t s_start; /* start sector no of partition */
include/linux/types.h:typedef __kernel_daddr_t daddr_t;
arch/parisc/hpux/sys_hpux.c: int32_t f_tfree; /* total free (daddr_t) */
The use of daddr_t in freevxfs may give different in core and disk
layouts on different machines. Is that intended?.
Its definition is not consistent. Some 32 bit machines use int, some
use long. Some 64 bit machines use int, some use long.
include/linux/types.h:typedef __kernel_daddr_t daddr_t;
include/linux/types.h: __kernel_daddr_t f_tfree;
include/linux/mtio.h: __kernel_daddr_t mt_fileno; /* number of current file on tape */
include/linux/mtio.h: __kernel_daddr_t mt_blkno; /* current block number */
include/asm-i386/posix_types.h:typedef int __kernel_daddr_t;
include/asm-mips/posix_types.h:typedef long __kernel_daddr_t;
include/asm-alpha/posix_types.h:typedef int __kernel_daddr_t;
include/asm-m68k/posix_types.h:typedef int __kernel_daddr_t;
include/asm-sparc/posix_types.h:typedef long __kernel_daddr_t;
include/asm-ppc/posix_types.h:typedef int __kernel_daddr_t;
include/asm-sparc64/posix_types.h:typedef int __kernel_daddr_t;
include/asm-arm/posix_types.h:typedef int __kernel_daddr_t;
include/asm-sh/posix_types.h:typedef int __kernel_daddr_t;
include/asm-ia64/posix_types.h:typedef int __kernel_daddr_t;
include/asm-mips64/posix_types.h:typedef long __kernel_daddr_t;
include/asm-s390/posix_types.h:typedef int __kernel_daddr_t;
include/asm-parisc/posix_types.h:typedef int __kernel_daddr_t;
include/asm-cris/posix_types.h:typedef int __kernel_daddr_t;
include/asm-s390x/posix_types.h:typedef int __kernel_daddr_t;
Do we still need daddr_t?
This question was raised when I saw patches for ia64 that replaced u32
with unsigned long because ia64 needs 64 bit. Shouldn't we be using a
consistent type that holds kernel addresses as numbers? off_t and
loff_t are not suitable. caddr_t is close but uses char *, sometimes
you want just a number. What about defining kaddr_t?
next reply other threads:[~2001-08-16 2:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-16 2:40 Keith Owens [this message]
2001-08-16 2:57 ` daddr_t is inconsistent and barely used Christoph Hellwig
2001-08-16 3:14 ` Keith Owens
2001-08-16 3:21 ` Christoph Hellwig
2001-08-16 3:52 ` Albert D. Cahalan
2001-08-16 3:59 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9980.997929632@kao2.melbourne.sgi.com \
--to=kaos@ocs.com.au \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox