Dear all, I have finally got round to check Naohiro's hfsplus journalling work (git://github.com/naota/hfsplus.git). The result, in a nutshell, is a tar ball: http://htl10.users.sourceforge.net/patchsets/hfsplus_3.0_rfc/hfsplus_standalone.tar.gz which you can do make -C /lib/modules/<kernel_version>/build/ M=`pwd` against your system's approx 3.0 bits to build a journal-enabled hfsplus kernel module to replace the one you had. *CAVEATE BELOW*. The 22 patches is in a sub-dir inside the tar-ball, as well as in http://htl10.users.sourceforge.net/patchsets/hfsplus_3.0_rfc/ #1, #2 was just Naohiro's work as he did it (and as on his github area) rebased slightly from 3.0rcX to 3.0 proper. I found that it did not build with journalling enabled, actually, so, patch #3-#22 are what I added on top. #14, #20, #22 are modifications/READMEs to make the tarball built out-of-tree (and not needed for other purpose), #17 is a a new fix for a small formatting issue. The rest (16 of them) are adjustments for about 8 API changes between 2.6.15 and 2.6.40/3.0.x . - I am not sure my buffer_head related patches (#4, #18. #21) are correct. I think #4 is, but #18 and #21 are probably wrong and/or need to do something else. Suggestions? (possibly from Christoph Hellwig). - consider that these are not trivial breakages, I wouldn't even let this tarball touch any real data/disk yet; there are probably ways of testing this safely (e.g. loop-back-mounted disk image) but it is probably wise to leave it for a bit until patch #2 from Naohiro is broken down and reviewed properly. - I have a couple of questions for Naohiro and a couple of comments. - considered that your 3.0rcX doesn't build, what version/branch did you spend your time on? You did come up with a useful fix, so it would appear that you spend a considerable amount of time on 3.0rcX, without working on journalling directly. - Guess that's another weak area Naohiro can improve in years to come: getting bogged-down by interesting/challenging issues instead of being responsible and spending time on what one has to meet a deadline for. While we all like to work on our own little pet projects/ideas, when it involves others and accountability to others, sometimes one has to prioritize. - that's in addition to the general poor (and lack of) communication: that patch #2 comes with only a 'one-liner' (no before [how it got to how it is] and no after [how it does not build]); that you choose not to mention that you are having exams (it would seems around now) until after I told you that you should not continue; - I understand bereavement, and I did ask if we should abort before we started. It is okay to grief for the dead, and it is okay to say no, you cannot cope due to personal circumstances and want to drop out; but it is not okay to take on a task formally and then do it badly. People important in our life pass away - it is okay to grief but it is not a good way to honour the dearly departed, to do poorly in life. And I am not convinced... exam timetables are predictable in advance (unlike a family's death) but there were no mention of this in the initial GSoC proposal/timeline. So any how, I'll try to find time to have a look at the #2 and how it compared with actually rebase'ing the original netgear patch forward. Hin-Tak -- 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
