On 05/26/2010 08:39 PM, Dean Hildebrand wrote: > Try to remember that this isn't some new feature that we are disabling, > or a new way of doing things, this is a primary I/O path. We MUST fix > this with the B-list code submission, so why go through the hassle of > searching through old patches and tags to find it. No, this is no hassle. uncommenting old code and hopping for the best is the hassle. (insert here the explanation from previous mail) > > If you want to talk about a *REAL* solution, then we need to figure out > who broke O_DIRECT and reject their patches until they fix it. You > can't submit patches that break a primary I/O path. But again, since we > are focused on A-list items, ifdef'ing the code out for now in the > B-list branch seems like a reasonable compromise. > No "ifdef'ing the code out" is never a "reasonable compromise" if you want then keep it in a separate clean patch, with "BROKEN:" at subject line and committed in a branch that is above the pnfs-all-latest. So it can be rebased from time to time, but not included in the regular test scenario, until fixed. (Which is BTW what it means the keep it out-of-tree, these git games are done routinely, every day) Boaz > Dean > > Boaz Harrosh wrote: >> On 05/25/2010 11:14 PM, Dean Hildebrand wrote: >> >>> >>>> I can send some post_submit patches with the code ifdef'ed out if people would be content with that. >>>> >>>> >>> Thanks for the background. I would be much happier if you sent patches >>> with the code ifdef'd out, added with the comment in the code regarding >>> which patches you believe introduced the problem. >>> >>> Dean >>> >>>> Fred >>>> >> >> I disagree. Source code is not a version management system. We have git >> for that. The code is never lost it is there for eternity in the git >> tree. We could ask Benny to tag the last branch that had broken directIO >> as LAST_directIO_VERSION for easy random access at future time. >> >> If in the future someone smart wants to forward port the code and fix it >> then the *right* way to do it is by manual octopus merge at the point of >> branch. >> Never, Never uncomment out code that was sitting collecting dust. >> Manual octopus merge I mean using the two diffs from the two sides of the >> branch, and replaying one on the other. For instance if at one patch >> a function was moved, then redo the move of the current function again, not >> leave the old code as it was before. Let the merge point out the points of >> friction. Because you see, with commented code, there is never a merge >> conflict it will always uncomment. >> >> And anyway the Kernel people will never accept code in comments. There >> are out-of-tree gits to do that. So I don't even think it is an option. >> The pnfs branches are patches that should eventually go upstream. Or >> are currently the only option for the testing of upstream code. >> >> Boaz >> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
