On Mon, Feb 13, 2012 at 02:43:41AM +0100, Kai Bankett wrote: > Small qnx4 cleanup patch. > - removes .writepage, .write_begin and .write_end (+callback functions) > - removes '.' path checking in namei.c (handled on upper layers) Applied. FWIW, after looking at fs/qnx4... *OUCH* * qnx4_bread()/qnx4_getblk() is completely pointless - the sole caller is going to call qnx4_block_map() *anyway*, so we might as well just feed that value to sb_bread(). * extent blocks handling is fishy - e.g. if you have an extent block with 0 extents in it, the damn thing will treat that as if it contained 1 extent. If it's really invalid (and it probably is), that might be a sane mitigation strategy, but otherwise it's a bug; in any case, that shouldn't be silent. It also leaks references to buffer_head if it runs into extent block with invalid signature. It definitely could've used a bit of caching - storing the last matched extent in the in-core inode and skipping the entire "walk the whole extent chain" thing would be a clear win. It also has a problem with error reporting - it returns (unsigned long)-EIO and callers have no idea what to do with that (they do understand 0 as "no such block", but that's it; you'll _probably_ end up with sb_bread() unhappy with huge block number, so it'll end up with screaming block layer) * readdir and lookup handling relies on running into NULs in directories. Neither bothers to check for combination of "used" and "link" bits being invalid. BTW, neither handles long names (present in qnx4 filesystems on recent enough versions). Overall, the code could use quite a bit of cleanup. I don't know if they have evaluation images that could run under qemu and if the license allows experimenting with fs images anyway; if anyone knows (or can run the tests on their box), please yell - I'd rather not play with cleanup patches without testing, but the codebase isn't large or complex enough to make writing the patches to test particulary hard. -- 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
