[PATCH] Unify CONFIG_LBD and CONFIG_LSF handling

[PATCH] Unify CONFIG_LBD and CONFIG_LSF handling

[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 these days.

Signed-off-by: Matthew Wilcox <matthew@wil.cx>

Index: ./block/Kconfig
===================================================================
RCS file: /var/cvs/linux-2.6/block/Kconfig,v
retrieving revision 1.4
diff -u -p -r1.4 Kconfig
--- ./block/Kconfig	3 Apr 2006 13:44:01 -0000	1.4
+++ ./block/Kconfig	19 Apr 2006 13:43:26 -0000
@@ -1,11 +1,9 @@
 #
 # Block layer core configuration
 #
-#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
@@ -26,7 +24,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.
Index: ./include/asm-h8300/types.h
===================================================================
RCS file: /var/cvs/linux-2.6/include/asm-h8300/types.h,v
retrieving revision 1.5
diff -u -p -r1.5 types.h
--- ./include/asm-h8300/types.h	3 Apr 2006 13:45:48 -0000	1.5
+++ ./include/asm-h8300/types.h	19 Apr 2006 13:40:47 -0000
@@ -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__ */
Index: ./include/asm-i386/types.h
===================================================================
RCS file: /var/cvs/linux-2.6/include/asm-i386/types.h,v
retrieving revision 1.4
diff -u -p -r1.4 types.h
--- ./include/asm-i386/types.h	3 Apr 2006 13:45:49 -0000	1.4
+++ ./include/asm-i386/types.h	19 Apr 2006 13:36:02 -0000
@@ -58,16 +58,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__ */
Index: ./include/asm-mips/types.h
===================================================================
RCS file: /var/cvs/linux-2.6/include/asm-mips/types.h,v
retrieving revision 1.6
diff -u -p -r1.6 types.h
--- ./include/asm-mips/types.h	3 Apr 2006 13:45:53 -0000	1.6
+++ ./include/asm-mips/types.h	19 Apr 2006 13:36:08 -0000
@@ -94,16 +94,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__ */
Index: ./include/asm-powerpc/types.h
===================================================================
RCS file: /var/cvs/linux-2.6/include/asm-powerpc/types.h,v
retrieving revision 1.3
diff -u -p -r1.3 types.h
--- ./include/asm-powerpc/types.h	3 Apr 2006 13:45:55 -0000	1.3
+++ ./include/asm-powerpc/types.h	19 Apr 2006 13:36:14 -0000
@@ -98,16 +98,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__ */
Index: ./include/asm-s390/types.h
===================================================================
RCS file: /var/cvs/linux-2.6/include/asm-s390/types.h,v
retrieving revision 1.6
diff -u -p -r1.6 types.h
--- ./include/asm-s390/types.h	3 Apr 2006 13:45:56 -0000	1.6
+++ ./include/asm-s390/types.h	19 Apr 2006 13:36:20 -0000
@@ -88,16 +88,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__    */
Index: ./include/asm-sh/types.h
===================================================================
RCS file: /var/cvs/linux-2.6/include/asm-sh/types.h,v
retrieving revision 1.5
diff -u -p -r1.5 types.h
--- ./include/asm-sh/types.h	3 Apr 2006 13:45:57 -0000	1.5
+++ ./include/asm-sh/types.h	19 Apr 2006 13:36:26 -0000
@@ -53,16 +53,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__ */
Index: ./include/asm-x86_64/types.h
===================================================================
RCS file: /var/cvs/linux-2.6/include/asm-x86_64/types.h,v
retrieving revision 1.5
diff -u -p -r1.5 types.h
--- ./include/asm-x86_64/types.h	14 Sep 2005 12:57:48 -0000	1.5
+++ ./include/asm-x86_64/types.h	27 Apr 2006 05:44:25 -0000
@@ -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__ */
Index: ./include/linux/types.h
===================================================================
RCS file: /var/cvs/linux-2.6/include/linux/types.h,v
retrieving revision 1.11
diff -u -p -r1.11 types.h
--- ./include/linux/types.h	3 Apr 2006 13:46:02 -0000	1.11
+++ ./include/linux/types.h	19 Apr 2006 13:40:32 -0000
@@ -130,14 +130,19 @@ typedef		__s64		int64_t;
 
 /*
  * The type used for indexing onto a disc or disc partition.
- * 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
 

Re: [PATCH] Unify CONFIG_LBD and CONFIG_LSF handling

[Roman Zippel]

Hi,

On Mon, 19 Jun 2006, Matthew Wilcox wrote:

> Index: ./block/Kconfig
> ===================================================================
> RCS file: /var/cvs/linux-2.6/block/Kconfig,v
> retrieving revision 1.4
> diff -u -p -r1.4 Kconfig
> --- ./block/Kconfig	3 Apr 2006 13:44:01 -0000	1.4
> +++ ./block/Kconfig	19 Apr 2006 13:43:26 -0000
> @@ -1,11 +1,9 @@
>  #
>  # Block layer core configuration
>  #
> -#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
> @@ -26,7 +24,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.

While you're at it, could you please take care of bug #6719 and fix the 
LSF help text?
Thanks.

bye, Roman

Re: [PATCH] Unify CONFIG_LBD and CONFIG_LSF handling

[Matthew Wilcox]

On Tue, Jun 20, 2006 at 04:20:53PM +0200, Roman Zippel wrote:
> Hi,
> 
> On Mon, 19 Jun 2006, Matthew Wilcox wrote:
> >  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.
> 
> While you're at it, could you please take care of bug #6719 and fix the 
> LSF help text?
> Thanks.

I don't really understand the complaint.  If <rare condition applies>,
say Y, otherwise say N.  If unsure, say Y.  The default is N.  Perhaps
all that's needed is to spell out the implications of saying Y?  How
about:

	  This option allows 32-bit systems to support files larger than
	  2 Terabytes, at a cost of increased kernel memory usage.  Most
	  people do not need the overhead and should answer N to this
	  question, but if you do not understand this question, answering
	  Y is safest.

Or is that too verbose?

NB: Anyone suggesting that we should say "Tibibytes" instead of
Terabytes there will be hunted down and brutally slain.  That is all.

Re: [PATCH] Unify CONFIG_LBD and CONFIG_LSF handling

[Roman Zippel]

Hi,

On Tue, 20 Jun 2006, Matthew Wilcox wrote:

> On Tue, Jun 20, 2006 at 04:20:53PM +0200, Roman Zippel wrote:
> > Hi,
> > 
> > On Mon, 19 Jun 2006, Matthew Wilcox wrote:
> > >  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.
> > 
> > While you're at it, could you please take care of bug #6719 and fix the 
> > LSF help text?
> > Thanks.
> 
> I don't really understand the complaint.  If <rare condition applies>,
> say Y, otherwise say N.  If unsure, say Y.  The default is N.  Perhaps
> all that's needed is to spell out the implications of saying Y?  How
> about:
> 
> 	  This option allows 32-bit systems to support files larger than
> 	  2 Terabytes, at a cost of increased kernel memory usage.  Most
> 	  people do not need the overhead and should answer N to this
> 	  question, but if you do not understand this question, answering
> 	  Y is safest.
> 
> Or is that too verbose?

How likely is it that someone who doesn't understand the question needs 
this option? I think N is a safe answer here.

bye, Roman

RE: [PATCH] Unify CONFIG_LBD and CONFIG_LSF handling

[Matt LaPlante]

> On Tue, 20 Jun 2006, Matthew Wilcox wrote:
> 
> > On Tue, Jun 20, 2006 at 04:20:53PM +0200, Roman Zippel wrote:
[snip]
> >
> > I don't really understand the complaint.  If <rare condition applies>,
> > say Y, otherwise say N.  If unsure, say Y.  The default is N.  Perhaps
> > all that's needed is to spell out the implications of saying Y?  How
> > about:
> >
> > 	  This option allows 32-bit systems to support files larger than
> > 	  2 Terabytes, at a cost of increased kernel memory usage.  Most
> > 	  people do not need the overhead and should answer N to this
> > 	  question, but if you do not understand this question, answering
> > 	  Y is safest.
> >
> > Or is that too verbose?
> 
> How likely is it that someone who doesn't understand the question needs
> this option? I think N is a safe answer here.
> 
> bye, Roman

This is the impression I had as well.  Even if you disagree though, I was
equally confused by the fact that if we say to answer Y as default, why is
the kconfig default already N?

-
Matt LaPlante

Re: [PATCH] Unify CONFIG_LBD and CONFIG_LSF handling

[Arjan van de Ven]

> > Or is that too verbose?
> 
> How likely is it that someone who doesn't understand the question needs 
> this option? I think N is a safe answer here.

N is not the safe answer; Y is. If you set it to N you can't read all
your files (if there is a big one) etc etc.
The safe-but-a-bit-slower answer really is Y.

Re: [PATCH] Unify CONFIG_LBD and CONFIG_LSF handling

[Matthew Wilcox]

On Tue, Jun 20, 2006 at 11:53:24AM -0400, Matt LaPlante wrote:
> > How likely is it that someone who doesn't understand the question needs
> > this option? I think N is a safe answer here.
> 
> This is the impression I had as well.  Even if you disagree though, I was
> equally confused by the fact that if we say to answer Y as default, why is
> the kconfig default already N?

The *default* is N as that's the answer most people want.  The *safe*
answer is Y as it won't prevent you from getting access to your data.
Makes sense?

Re: [PATCH] Unify CONFIG_LBD and CONFIG_LSF handling

[Roman Zippel]

Hi,

On Tue, 20 Jun 2006, Matthew Wilcox wrote:

> On Tue, Jun 20, 2006 at 11:53:24AM -0400, Matt LaPlante wrote:
> > > How likely is it that someone who doesn't understand the question needs
> > > this option? I think N is a safe answer here.
> > 
> > This is the impression I had as well.  Even if you disagree though, I was
> > equally confused by the fact that if we say to answer Y as default, why is
> > the kconfig default already N?
> 
> The *default* is N as that's the answer most people want.  The *safe*
> answer is Y as it won't prevent you from getting access to your data.
> Makes sense?

This would imply that most people with 32bit systems have 2TB files, which 
I think is rather unlikely. Distributions can turn this option on, but I 
think people who compile their own kernel, either understand this option 
or don't need it.

bye, Roman

Re: [PATCH] Unify CONFIG_LBD and CONFIG_LSF handling

[Matthew Wilcox]

On Tue, Jun 20, 2006 at 06:12:50PM +0200, Roman Zippel wrote:
> Hi,
> 
> On Tue, 20 Jun 2006, Matthew Wilcox wrote:
> > The *default* is N as that's the answer most people want.  The *safe*
> > answer is Y as it won't prevent you from getting access to your data.
> > Makes sense?
> 
> This would imply that most people with 32bit systems have 2TB files, which 
> I think is rather unlikely. Distributions can turn this option on, but I 
> think people who compile their own kernel, either understand this option 
> or don't need it.

I think it implies exactly the opposite.

In any case, the length of this thread answers your question from earlier:
No, I won't fix bug 6719 as part of this patch.  It's a completely
unrelated issue and the problem is ill-defined.  It's also something
that's infinitely arguable.

The original patch is simple and fixes one problem: that architecture
people are supposed to learn about LSF and LBD when it really has no
effect on their architecture.

RE: [PATCH] Unify CONFIG_LBD and CONFIG_LSF handling

[Matt LaPlante]

> -----Original Message-----
> From: Arjan van de Ven [mailto:arjan@infradead.org]
> Sent: Tuesday, June 20, 2006 11:59 AM
> To: Roman Zippel
> Cc: Matthew Wilcox; Linus Torvalds; linux-kernel@vger.kernel.org;
> webmaster@cyberdogtech.com
> Subject: Re: [PATCH] Unify CONFIG_LBD and CONFIG_LSF handling
> 
> 
> > > Or is that too verbose?
> >
> > How likely is it that someone who doesn't understand the question needs
> > this option? I think N is a safe answer here.
> 
> N is not the safe answer; Y is. If you set it to N you can't read all
> your files (if there is a big one) etc etc.
> The safe-but-a-bit-slower answer really is Y.
> 

So should default be changed to Y?  It's currently N for kconfig, despite
the recommendation to the contrary.