* daddr_t is inconsistent and barely used
@ 2001-08-16 2:40 Keith Owens
2001-08-16 2:57 ` Christoph Hellwig
0 siblings, 1 reply; 6+ messages in thread
From: Keith Owens @ 2001-08-16 2:40 UTC (permalink / raw)
To: linux-kernel
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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: daddr_t is inconsistent and barely used
2001-08-16 2:40 daddr_t is inconsistent and barely used Keith Owens
@ 2001-08-16 2:57 ` Christoph Hellwig
2001-08-16 3:14 ` Keith Owens
0 siblings, 1 reply; 6+ messages in thread
From: Christoph Hellwig @ 2001-08-16 2:57 UTC (permalink / raw)
To: Keith Owens; +Cc: linux-kernel
In article <9980.997929632@kao2.melbourne.sgi.com> you wrote:
> daddr_t is barely used in the kernel. 2.4.8.
>
> The use of daddr_t in freevxfs may give different in core and disk
> layouts on different machines. Is that intended?.
No, it may not. Please double check.
> Do we still need daddr_t?
I think so, in fact we really should use daddr_t for all incore disk
addessing.
> 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?
vaddr_t? That's consintant to virt_to_phys, virt_to_bus, etc.. and
what SVR5 uses.
Christoph
--
Whip me. Beat me. Make me maintain AIX.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: daddr_t is inconsistent and barely used
2001-08-16 2:57 ` Christoph Hellwig
@ 2001-08-16 3:14 ` Keith Owens
2001-08-16 3:21 ` Christoph Hellwig
0 siblings, 1 reply; 6+ messages in thread
From: Keith Owens @ 2001-08-16 3:14 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-kernel
On Thu, 16 Aug 2001 04:57:34 +0200,
Christoph Hellwig <hch@ns.caldera.de> wrote:
>In article <9980.997929632@kao2.melbourne.sgi.com> you wrote:
>> daddr_t is barely used in the kernel. 2.4.8.
>>
>> The use of daddr_t in freevxfs may give different in core and disk
>> layouts on different machines. Is that intended?.
>
>No, it may not. Please double check.
That is why I said "may". It seemed puzzling that freevxfs used
vx_daddr_t for almost everything but daddr_t for a couple of fields.
An inconsistency with no obvious reason.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: daddr_t is inconsistent and barely used
2001-08-16 3:14 ` Keith Owens
@ 2001-08-16 3:21 ` Christoph Hellwig
2001-08-16 3:52 ` Albert D. Cahalan
0 siblings, 1 reply; 6+ messages in thread
From: Christoph Hellwig @ 2001-08-16 3:21 UTC (permalink / raw)
To: Keith Owens; +Cc: linux-kernel
On Thu, Aug 16, 2001 at 01:14:20PM +1000, Keith Owens wrote:
> On Thu, 16 Aug 2001 04:57:34 +0200,
> Christoph Hellwig <hch@ns.caldera.de> wrote:
> >In article <9980.997929632@kao2.melbourne.sgi.com> you wrote:
> >> daddr_t is barely used in the kernel. 2.4.8.
> >>
> >> The use of daddr_t in freevxfs may give different in core and disk
> >> layouts on different machines. Is that intended?.
> >
> >No, it may not. Please double check.
>
> That is why I said "may". It seemed puzzling that freevxfs used
> vx_daddr_t for almost everything but daddr_t for a couple of fields.
> An inconsistency with no obvious reason.
vx_daddr_t is for disk structures, daddr_t for core.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: daddr_t is inconsistent and barely used
2001-08-16 3:21 ` Christoph Hellwig
@ 2001-08-16 3:52 ` Albert D. Cahalan
2001-08-16 3:59 ` Christoph Hellwig
0 siblings, 1 reply; 6+ messages in thread
From: Albert D. Cahalan @ 2001-08-16 3:52 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Keith Owens, linux-kernel
Christoph Hellwig writes:
>>> In article <9980.997929632@kao2.melbourne.sgi.com> you wrote:
>>>> The use of daddr_t in freevxfs may give different in core
>>>> and disk layouts on different machines. Is that intended?.
...
> vx_daddr_t is for disk structures, daddr_t for core.
This is asking for trouble. The disk structures aren't about
to change. See include/linux/ext2_fs.h for a safe way to do
the on-disk structure. For the in-core stuff, "unsigned long"
is a perfectly fine data type -- and yes I know it gets wider
with a 64-bit system.
To save you the trouble of looking up my example:
/*
* Structure of a blocks group descriptor
*/
struct ext2_group_desc
{
__u32 bg_block_bitmap; /* Blocks bitmap block */
__u32 bg_inode_bitmap; /* Inodes bitmap block */
__u32 bg_inode_table; /* Inodes table block */
__u16 bg_free_blocks_count; /* Free blocks count */
__u16 bg_free_inodes_count; /* Free inodes count */
__u16 bg_used_dirs_count; /* Directories count */
__u16 bg_pad;
__u32 bg_reserved[3];
};
Don't forget to add explicit padding as needed to give natural alignment.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: daddr_t is inconsistent and barely used
2001-08-16 3:52 ` Albert D. Cahalan
@ 2001-08-16 3:59 ` Christoph Hellwig
0 siblings, 0 replies; 6+ messages in thread
From: Christoph Hellwig @ 2001-08-16 3:59 UTC (permalink / raw)
To: Albert D. Cahalan; +Cc: Keith Owens, linux-kernel
On Wed, Aug 15, 2001 at 11:52:37PM -0400, Albert D. Cahalan wrote:
> Christoph Hellwig writes:
> >>> In article <9980.997929632@kao2.melbourne.sgi.com> you wrote:
>
> >>>> The use of daddr_t in freevxfs may give different in core
> >>>> and disk layouts on different machines. Is that intended?.
> ...
> > vx_daddr_t is for disk structures, daddr_t for core.
>
> This is asking for trouble. The disk structures aren't about
> to change. See include/linux/ext2_fs.h for a safe way to do
> the on-disk structure. For the in-core stuff, "unsigned long"
> is a perfectly fine data type -- and yes I know it gets wider
> with a 64-bit system.
Please take a look how vx_daddr_t is defined - just because I prefer
descriptive names I am not stupid.
Christoph
> Don't forget to add explicit padding as needed to give natural alignment.
Thanks for you help, I have never worked with structure layouts before..
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2001-08-16 4:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-08-16 2:40 daddr_t is inconsistent and barely used Keith Owens
2001-08-16 2:57 ` 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox