On Tue, 2009-04-14 at 06:00 +0900, Paul Mundt wrote: > On Mon, Apr 13, 2009 at 09:32:48PM +0100, Adrian McMenamin wrote: > > I know this still has issues that others have raised but I wanted to > > post a version before the end of the long weekend... > > > Make sure all of the folks that had comments are included in the Cc on > future versions. If they haven't seen the updated version and are > therefore unable to comment on it, that is not an indicator that the > issues have been addressed. Fair point. Did think about this but wasn't sure what the correct etiquette is, as sometimes people don't want more email, but will do so in future. > > Reviewing code is tedious work at best, making people that have taken the > time to participate in review do even more work to find updated versions > that may or may not have addressed their issues is remarkably poor > etiquette at best, especially when they haven't completed their review. > As far as I can see the three issues I haven't addressed were posting a further patch to magic.h and a couple of *suggestions* about code style. I will fix these points in due course, for sure. I have taken on board, afaics, all the substantive points for which thanks ... > > > A few people commented that this is a bit long for a single file - but > > it is comparable to other files in the filesystem hierarchy - comments > > welcome. > > ... > > Furthermore, the fact other file systems haven't done so is not an excuse > for you not to, especially as their reasons for doing so might be valid > (you of course haven't bothered citing what other file systems you are > referring to, so one can only vaguely postulate, though at least the > arguments for things like cramfs do not apply to vmufat). > I didn't say that it was - I was offering my explanation for having taken the decision to make it all one file and then seeing what the bounce back was... there are in fact a very large number of filesystems like this, not least of which of course is ext2 which has longer inode.c and super.c files than this inode.c > You should also think about whether you really want to go down the road > of decoupling this from the VMU device dependencies. vmufat is not and > never will be a general purpose file system, the on-disk format, > limitation in block numbering, etc. are all directly tied to the VMU > itself. Since you cited emulators as a potential user, these should be > emulating the VMU itself anyways before you worry about layering vmufat > on top of it. Trying to position this as a general purpose file system > will bring you a world of pain you really don't want. The two compromises are that on a failed read of a block it tries again (as experience suggest that fixes most issues with the flaky VMU hardware - though I doubt emulator builders will replicate that) and that it does not write out a new date for the "superblock" on a change of the filesystem - to avoid wear on the flash on the VMU, but again not an issue for most emulator writers - I think the Kconfig makes it pretty clear this isn't a general purpose filesystem. -- 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
