Hi,
> > This is a patch to add blkcnt_t as the type of inode.i_blocks.
> > This enables you to make the size of blkcnt_t either 4 bytes or 8 bytes
> > on 32 bits architecture with CONFIG_LSF.
>
> What was the rationale behind CONFIG_LSF? It's a bit of an ugly thing and
> I'm wondering if we wouldn't be better off just removing it and simply
> fixing >2TB support for all .configs?
We should avoid needless growth of heavily-used structure such as
inode for a small system like embedded system.
So I make it possible to configure the size of i_blocks with CONFIG_LSF.
> Do the common userspace tools need to be updated for this, or do they
> already get it right?
glibc's st_blocks is always 8 bytes as below.
__blkcnt64_t st_blocks;
On the original kernel, a padding for st_blocks is set at appropriate
location for each endian types as below.
So, there is no need to fix user program(glibc).
include/asm-i386/stat.h:
--------------------------------------------------------------------------
unsigned long st_blocks; /* Number 512-byte blocks allocated. */
unsigned long __pad4; /* future possible st_blocks high bits */
---------------------------------------------------------------------------
include/asm-m68k/stat.h:
--------------------------------------------------------------------------
unsigned long __pad4; /* future possible st_blocks high bits */
unsigned long st_blocks; /* Number 512-byte blocks allocated. */
--------------------------------------------------------------------------
-- Takashi Sato
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
