FUJITA Tomonori wrote: > On Wed, 11 Mar 2009 16:33:01 +0200 > Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote: > >> FUJITA Tomonori wrote: >>> On Tue, 03 Mar 2009 12:15:34 +0200 >>> Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote: >>> >>>>> blen = sizeof(buf); >>>>> >>>>> slen = sizeof(ss); >>>>> - conn->tp->ep_getsockname(conn, (struct sockaddr *) &ss, >>>>> - &slen); >>>>> + ret = conn->tp->ep_getsockname(conn, >>>>> + (struct sockaddr *) &ss, &slen); >>>> TOMO if you are already experimenting, it might work if &slen is left >>>> untouched and is passed as returned from getsockname to getnameinfo. >>>> >>>> This might work on both Linux and BSD. >>> Yes, that's the proper way to handle this issue. >>> >>>> But then we must make sure >>>> that all transports set &slen to something good. >>> All the transports must make sure that ep_getsockname should set slen >>> because getsockname does for tcp. iser sets it up properly. >>> >>> So far looks like this patchset adds wrong workarounds instead doing >>> the right things. Sigh, I have to investigate all the patchset in a >>> line-by-line manner. >> This is not fair. And is not the proper working procedure. >> These problems existed before any BSD code. The BSD code did not add >> anything to the mess. > > You are completely wrong. > > If the main code has a problem, you should fix it. You should not add > a workaround for the BSD code to avoid the problem. > > Think about Linux kernel development; for example, vfs has a bug and > you develop your file system. You need to fix the vfs bug. You should > not add the workaround to your file system code to avoid the bug. > This is the wrong example. You say something right and you think it will win the argument. But it must be relevant, this example is not relevant. What I'm saying is that if I develop a filesystem, and I find something that can be done nicer, a cleanup to vfs code. I separate the two efforts. One patch will do the cleanup and, one or more patches will be submitted to the FS. If after the cleanup also the FS code needs to change then there will be a patch done for that, as to other FSs that might need to change because of the cleanup. I want BSD compatibility patches to not change ANYTHING, What is so hard to understand, patches that change something should be SEPARATE. > >> If you want to fix the Linux code then it should be done separately, >> by itself. In a different patchset. Which only fixes the Linux code. >> This way if you have a regression you can go back to something that >> worked before. Then if the Linux is fixed in a way compatible to BSD, >> the compatibility layer can be removed by a latter patch. >> >> Never MIX code changes with compatibility changes, because you cannot >> separate the two if something goes wrong. >> >> So what? Are you going to wait for all the Linux hacks and bugs fixed until >> you put the BSD code? this is not the way to work! > > This is the way to work. You should fix the root problems. > But there's never been a problem. This code works for years just fine. The problem at hand is BSD compatibility. As I said changes should be separate, cleanups is one thing, BSD code another. Most of the patches are BSD only stuff why can't they go in, they do nothing to the code. > >> Mean while I'm using my tree, and so will my users > > Drop such attitude; my code works for my users. I don't care about > your users. I care about only tgt. No! you drop your attitude. These are your users, hell I'm your user. I came with a problem, BSD. Now you queue me behind bureaucracy and second grade users. But there is one philosophical question you must answer: where was this problem before I came with BSD code? Thanks for your time and effort Boaz -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
