Skip to contentSkip to conversation

Centralise definitions of sector_t and blkcnt_t

PATCH Applied Matthew Wilcox 3 participants 3 messages Dec 4, 2006 – Dec 5, 2006

Subsystems (2)
Block layer Generic include/asm header files
lore
Share & tools
lore

Matthew Wilcox

author
#0 lore raw

PATCH 1/1 Centralise definitions of sector_t and blkcnt_t

CONFIG_LBD and CONFIG_LSF are spread into asm/types.h for no particularly good reason. Centralising the definition in linux/types.h means that arch maintainers don't need to bother adding it, as well as fixing the problem with x86-64 users being asked to make a decision that has absolutely no effect. The H8/300 porters seem particularly confused since I'm not aware of any microcontrollers that need to support 2TB filesystems.

Signed-off-by Matthew Wilcox <[email protected]>
block/Kconfig +2 -4
index 83766a6..a50f481 100644
@@ -19,11 +19,9 @@ config BLOCK
 
 if BLOCK
 
-#XXX - it makes sense to enable this only for 32-bit subarch's, not for x86_64
-#for instance.
 config LBD
 	bool "Support for Large Block Devices"
-	depends on X86 || (MIPS && 32BIT) || PPC32 || (S390 && !64BIT) || SUPERH || UML
+	depends on !64BIT
 	help
 	  Say Y here if you want to attach large (bigger than 2TB) discs to
 	  your machine, or if you want to have a raid or loopback device

@@ -44,7 +42,7 @@ config BLK_DEV_IO_TRACE
 
 config LSF
 	bool "Support for Large Single Files"
-	depends on X86 || (MIPS && 32BIT) || PPC32 || ARCH_S390_31 || SUPERH || UML
+	depends on !64BIT
 	help
 	  Say Y here if you want to be able to handle very large files (bigger
 	  than 2TB), otherwise say N.
include/asm-avr32/types.h +0 -5
index 3f47db9..2bff153 100644
@@ -57,11 +57,6 @@ typedef unsigned long long u64;
 
 typedef u32 dma_addr_t;
 
-#ifdef CONFIG_LBD
-typedef u64 sector_t;
-#define HAVE_SECTOR_T
-#endif
-
 #endif /* __ASSEMBLY__ */
 
 #endif /* __KERNEL__ */
include/asm-h8300/types.h +0 -6
index da2402b..2a8b1b2 100644
@@ -55,12 +55,6 @@ typedef unsigned long long u64;
 
 typedef u32 dma_addr_t;
 
-#define HAVE_SECTOR_T
-typedef u64 sector_t;
-
-#define HAVE_BLKCNT_T
-typedef u64 blkcnt_t;
-
 #endif /* __KERNEL__ */
 
 #endif /* __ASSEMBLY__ */
include/asm-i386/types.h +0 -10
index 4b4b295..ad0a55b 100644
@@ -57,16 +57,6 @@ typedef u32 dma_addr_t;
 #endif
 typedef u64 dma64_addr_t;
 
-#ifdef CONFIG_LBD
-typedef u64 sector_t;
-#define HAVE_SECTOR_T
-#endif
-
-#ifdef CONFIG_LSF
-typedef u64 blkcnt_t;
-#define HAVE_BLKCNT_T
-#endif
-
 #endif /* __ASSEMBLY__ */
 
 #endif /* __KERNEL__ */
include/asm-mips/types.h +0 -10
index 2b52e18..63a13c5 100644
@@ -93,16 +93,6 @@ typedef unsigned long long phys_t;
 typedef unsigned long phys_t;
 #endif
 
-#ifdef CONFIG_LBD
-typedef u64 sector_t;
-#define HAVE_SECTOR_T
-#endif
-
-#ifdef CONFIG_LSF
-typedef u64 blkcnt_t;
-#define HAVE_BLKCNT_T
-#endif
-
 #endif /* __ASSEMBLY__ */
 
 #endif /* __KERNEL__ */
include/asm-powerpc/types.h +0 -10
index d6fb56b..3b36375 100644
@@ -97,16 +97,6 @@ typedef struct {
 	unsigned long env;
 } func_descr_t;
 
-#ifdef CONFIG_LBD
-typedef u64 sector_t;
-#define HAVE_SECTOR_T
-#endif
-
-#ifdef CONFIG_LSF
-typedef u64 blkcnt_t;
-#define HAVE_BLKCNT_T
-#endif
-
 #endif /* __ASSEMBLY__ */
 
 #endif /* __KERNEL__ */
include/asm-s390/types.h +0 -10
index ae2951c..fc5d7cf 100644
@@ -87,16 +87,6 @@ typedef union {
 	} subreg;
 } register_pair;
 
-#ifdef CONFIG_LBD
-typedef u64 sector_t;
-#define HAVE_SECTOR_T
-#endif
-
-#ifdef CONFIG_LSF
-typedef u64 blkcnt_t;
-#define HAVE_BLKCNT_T
-#endif
-
 #endif /* ! __s390x__   */
 #endif /* __ASSEMBLY__  */
 #endif /* __KERNEL__    */
include/asm-sh/types.h +0 -10
index 3c09dd4..fd00dbb 100644
@@ -52,16 +52,6 @@ typedef unsigned long long u64;
 
 typedef u32 dma_addr_t;
 
-#ifdef CONFIG_LBD
-typedef u64 sector_t;
-#define HAVE_SECTOR_T
-#endif
-
-#ifdef CONFIG_LSF
-typedef u64 blkcnt_t;
-#define HAVE_BLKCNT_T
-#endif
-
 #endif /* __ASSEMBLY__ */
 
 #endif /* __KERNEL__ */
include/asm-x86_64/types.h +0 -3
index c86c2e6..2d4491a 100644
@@ -48,9 +48,6 @@ typedef unsigned long long u64;
 typedef u64 dma64_addr_t;
 typedef u64 dma_addr_t;
 
-typedef u64 sector_t;
-#define HAVE_SECTOR_T
-
 #endif /* __ASSEMBLY__ */
 
 #endif /* __KERNEL__ */
include/linux/types.h +9 -5
index 745c409..0351bf2 100644
@@ -136,15 +136,19 @@ typedef		__s64		int64_t;
  *
  * Linux always considers sectors to be 512 bytes long independently
  * of the devices real block size.
- *
- * If required, asm/types.h can override it and define
- * HAVE_SECTOR_T
  */
-#ifndef HAVE_SECTOR_T
+#ifdef CONFIG_LBD
+typedef u64 sector_t;
+#else
 typedef unsigned long sector_t;
 #endif
 
-#ifndef HAVE_BLKCNT_T
+/*
+ * The type of the inode's block count.
+ */
+#ifdef CONFIG_LSF
+typedef u64 blkcnt_t;
+#else
 typedef unsigned long blkcnt_t;
 #endif
Applied
#1 lore raw
Quoted 7 lines · Matthew Wilcox

CONFIG_LBD and CONFIG_LSF are spread into asm/types.h for no particularly good reason. Centralising the definition in linux/types.h means that arch maintainers don't need to bother adding it, as well as fixing the problem with x86-64 users being asked to make a decision that has absolutely no effect. The H8/300 porters seem particularly confused since I'm not aware of any microcontrollers that need to support 2TB filesystems.

Applied, since this is a good cleanup regardless.

I'd still be open to switching things around further, and allow even 64-bit architectures to say that they only want 32-bit sector_t's and page indexes (ie remove the "depends on !64BIT" and make the "unsigned long" case actually be "u32" instead, so that it literally switches between 32-bit or 64-bit values _regardless_ or architecture).

I don't know how big a deal it is, but I could imagine that we could actually save memory in a smaller "struct page", for example, on 64bit architectures by just using a 4-byte index.

For now, the !64BIT makes sense simply because a 64-bit architecture probably doesn't care, and might as well just use 64 bits anyway (ie you tend to have tons of memory there anyway). And I suspect it doesn't actually even help on 64-bits due to structure alignment etc issues, but am too lazy to go check.

Just thought I'd mention the possibility, in other words.

Linus

#2 lore raw
Quoted 8 lines · Linus Torvalds

[...]allow even 64-bit architectures to say that they only want 32-bit sector_t's and page indexes [...]

I don't know how big a deal it is, but I could imagine that we could actually save memory in a smaller "struct page", for example, on 64bit architectures by just using a 4-byte index.

Quoted 5 lines

For now, the !64BIT makes sense simply because a 64-bit architecture probably doesn't care, and might as well just use 64 bits anyway (ie you tend to have tons of memory there anyway). And I suspect it doesn't actually even help on 64-bits due to structure alignment etc issues, but am too lazy to go check.

sparc could benefit from this (someone go correct me if I am wrong). Not only in struct sizes, but maybe also a little in execution time.

	-`J'