On Sun, 7 May 2006, Al Viro wrote:
>
> FWIW, the only way to really deal with such structure would be to treat
> on-disk values as "fs-endian" and make the conversion to and from
> host-endian check the superblock. That would _really_ consolidate
> minix_..._bit() (turning them into __test_bit(nr ^ sbi->mangle, p), etc.)
Yeah, especially for bitmaps, it really _should_ be pretty simple, since
it's literally a bitwise xor of the bit number. It's actually worse for
things that truly have byte order dependencies where the values span bytes
and need re-ordering. For bits, that obviously will never be the case.
> If somebody wants to play with that code, they could just merge fs/minix
> into fs/sysv - that might very well turn out to be the right thing and
> a fun exercise. Codebases are very close - minixfs is a derivative of
> v7 filesystem, after all, and our fs/minix and fs/sysv had been kept
> mostly in sync.
Heh. Yes. The physical filesystem layout of minix is close to the old sysv
one, and the implementation ends up being pretty closely related too,
although the genealogy there is the other way around.
However, I thought the direct sysv descendants used linked lists of
free-block lists, not bitmaps? So while a lot of the _other_ part of the
filesystem layout is similar, the actual free-block handling is very
different. No?
So there are things that are very similar (directory layout, inode
format), and could probably be share, while other things (free block and
inode handling) are fundamentally different, no?
Linus
-
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]
