On Sun, 9 Dec 2001, Daniel Phillips wrote:
> Continuing the little warts list, there's Alan's comment re needing endian
> reversal on big endian machines.
Now that's a load of bollocks.
We _already_ keep the in-memory data in "disk format", and for a very
simple reason: that way we can naturally share all the functions that take
a pointer to a block tree, and they don't need to care whether the block
numbers come from a disk buffer or from the inode.
Which means that we have only _one_ set of routines for handling block
allocation etc, instead of duplicating them all.
Having in-core data in CPU-native byte order is _stupid_. We used to do
that, and I winced every time I had to look at all the duplication of
functions. I think it was early 2.3.x when Ingo did the page cache write
stuff where I fixed that - the people who had done the original ext2
endianness patches were just fairly lacking in brains (Hi, Davem ;), and
didn't realize that keeping inode data in host order was the fundamental
problem that caused them to have to duplicate all the functions.
So the _wart_ is in 2.2.x, which is just stupid and ugly, and keeps block
numbers in host data format - which causes no end of trouble. 2.4.x
doesn't have this problem, and could easily have a pointer to the on-disk
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:16 EST