Sorry for the re-send Jeff, I managed to screw up the CC so the list didn't get it; > > Let me know if there are tweaks that should be made > > or considered. > > A couple of comments: > > * It should be sufficient to fail lookup for paths that > match your pattern. If that fails, the caller will > never get to any others. You can use the quota > translator as an example for something like this. Ok, this is interesting. So if someone calls another fop .. say "open" ... against my brick/module, something (Fuse?) will make another, dependent, call to lookup first? If that's true then I can cut this all down to size. > * If you want to continue supporting this yourself, > then you can just leave the code as it is, though in > that case you'll want to consider building it "out of > tree" as I describe in my "Translator 101" post[1] > or do for some of my own translators[2]. > Otherwise you'll need to submit it as a patch > through Gerrit according to our standard workflow[3]. Thanks for the Translator articles/posts, I hadn't seen those. Per my previous patches, I'll publish code on my site under the GPL and you guys (Gluster/RedHat) can run them through whatever processes you choose. If it gets included in the GlusterFS package, then that's fine. If it gets ignored by the GlusterFS package, then that's fine also. > You'll also need to fix some of the idiosyncratic > indentation. I don't remember the current policy wrt > copyright assignment, but that might be required too. The weird indentation style used is not mine .. its what I gathered from the Gluster code that I read through. > [1] > http://hekafs.org/index.php/2011/11/translator-101-lesson-3-this-time-for-real/ > > [2] https://github.com/jdarcy/negative-lookup > > [3] > http://www.gluster.org/community/documentation/index.php/Development_Work_Flow > -- Ian Latter Late night coder .. http://midnightcode.org/
