On Sat, May 06, 2006 at 03:26:21PM -0700, Linus Torvalds wrote: > > > On Sat, 6 May 2006, Al Viro wrote: > > > > Warning: text below is a mild example of software coproarchaeology, > > so if you are easily squicked by tangled mess of bugs and dumb lossage, > > well... you've been warned. > > LOL. > > Maybe the right thing to do is to just disable minixfs for anything > big-endian except for m68k. > > It's not like it likely matters, and while we could save your description > of the problem as an amusing "how to really f*ck up" episode, I doubt > anybody really _cares_ in this case. Well... There's a minixfs v3 patch floating around, so somebody apparently cares ;-) 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.) and would give support of big- and little-endian images for free. That's what we do e.g. in fs/sysv and it's neither harder nor seriously bigger than existing code. Whether we care to do that is a separate question, of course, and I certainly agree that not a lot of people care about the damn thing these days, no matter which architecture it is. 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. Might merge minix v3 into that while we are at it... If there are any takers for that kind of work, go ahead and if you run into problems - feel free to ask on fsdevel or l-k. I promise to review and comment, but I'm not signing up for doing the entire thing myself. If nobody picks that up, marking it broken on affected platforms is probably the best solution. The only problem here is that we don't have a uniform way to say "it's little-endian" in Kconfig, but that's something we ought to do anyway - too many places have things like (BROKEN || !(SPARC || PPC || PARISC || M68K || FRV)) in Kconfig dependencies. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
