Messages in this thread | | | Date | Wed, 9 Aug 2006 23:40:19 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH 2/9] sector_t format string |
| |
On Wed, 09 Aug 2006 18:20:43 -0700 Mingming Cao <cmm@us.ibm.com> wrote:
> > Define SECTOR_FMT to print sector_t in proper format > > ... > > #define HAVE_SECTOR_T > typedef u64 sector_t; > +#define SECTOR_FMT "%llu"
We've thus-far avoided doing this. In fact a similar construct in device-mapper was recently removed.
Unlike many other attempts, this one appears to be correct (people usually get powerpc wrong, due to its u64=unsigned long).
That being said, I'm not really sure we want to add this. It produces rather nasty-looking source code and thus far we've just used %llu and we've typecasted the sector_t to `unsigned long long'. That happens in a lot of places in the kernel and perhaps we don't want to start innovating in ext4 ;)
That also being said... does a 32-bit sector_t make any sense on a 48-bit-blocknumber filesystem? I'd have thought that we'd just make ext4 depend on 64-bit sector_t and be done with it.
Consequently, sector_t should largely vanish from ext4 and JBD2, except for those places where it interfaces with the VFS and the block layer. Internally it should just use 64-bit quantities. That could be u64, but I'd suggest that the fs simply open-code `unsigned long long' so that we don't need to play any gams at all when passing these things into printk.
Finally, perhaps the code is printing block numbers too much ;)
<Notices E3FSBLK, wonders how that snuck through>
I'd suggest that "[patch] ext3: remove E3FSBLK" be written and merged before we clone ext4, too...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |