>> The login code is quite messy, and i failed in changing it to >> receive only char * buffers and sizes. >> So the simple approach did not work. > Understood. The approach really works? I guess so, if i understand what i did, and how i will go on from here, if it compiles and supports few iscsi/tcp sessions with and without chap. >> Note, that the patch that i sent does not break anything. > How it's guaranteed? It's never guaranteed, you know. There is nothing in it that knowingly breaks things. There can be bugs, and the code should be tested, but isn't it always the case? >> iser code (that you've got) fixes the bug, but all the objections and >> reservations, that you have raised previously (about the big patch etc.) >> are still valid. So i am a bit surprised that your highest priority >> was the merge. > Well, the iser code has been buggy for too long. Fine. Then let's make it happen :) >> If you are afraid of breaking iscsi/tcp by applying the patch directly >> to "master", perhaps another approach will work. You can start a new branch, >> from the "master", apply the last patch there, and i'll start sending patches >> destined for the new branch. >> I'll resend the new iser code, w/out duplicated login, then add a patch >> for bidi support and a few other small fixes i've made recently to iser. > Distributions will not ship a new branch. When the new iser > code (with bidi support) is ready, I'll merge it at a time. I did not meant the distributions at all. What is the process for making large or structural changes? I can work out it all by myself, making changes in the whole way iscsi code works and be happy with it. You will be probably less happy, and reluctant to even try such a thing. If i go small step at a time, then each time merging will pose a risk of breaking a release. So i propose opening a branch (say from 1.0.8), and merging the patches there after they are reviewed. We can ask all those guys who experienced data loss with iser to try the branch once it has the minimal new code in it. Then when it is tested, and has all the lacking features, we merge it, and only then the distros enter the game. Is it acceptable? Alexander -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html |