James Bottomley, on 12/17/2010 07:21 PM wrote: > On Fri, 2010-12-17 at 19:01 +0300, Vladislav Bolkhovitin wrote: >> James Bottomley, on 12/17/2010 06:22 PM wrote: >>> OK, I think this has reached the stage where it's been polished enough >>> outside mainline to the point where we can complete any remaining todo >>> items in-tree. >>> >>> So lets begin merging with the minimal target core and the TCM_Loop as >>> two separate commits. I think the target core may just fit under the >>> reflector mail length limits, but if not, you can send it as multiple >>> patches and I'll recombine them. >> >> Well, could somebody eventually explain what are advantages of LIO over >> SCST so you are choosing it? >> >> LIO is obviously worse all technically (see >> http://scst.sourceforge.net/comparison.html) as well as in the number of >> users and size of the community. Current in-rush attempts to make LIO >> _look_ not worse than SCST changed nothing in this area. > > To be honest, I don't really give a toss about niche feature > comparisons: both products have niche features the other doesn't. The > basic requirements in both products are solid. James, sorry, but your position is weak and absurd. In it maturity, quality and features don't matter. Following this logic Linux kernel and a student's home brewed OS kernel for his PhD work are equal. Obviously, this is wrong. No doubts, that all what Linux kernel can do with the same quality as it does can be added to the student's kernel sooner or later, ... but after several decades of hard work of thousands of people. Moreover, isn't Linux kernel and you as a maintainer supposed to choose what is ALREADY the best, not what is promising to become better somewhen in the future? Or not become. > If the niche feature has > customer value, my estimation is that it can easily be added (to either > product). If you eventually look on the technical comparison of SCST and LIO, you'll see that SCST is far ahead in practically everywhere, in any major area. Why not to compare yourself instead of blindly relying on what NicholasB and his people are chea^H^H^H^Hsaying. >> In the resent threads how many people voted for LIO? Nobody. How many >> for SCST? Many. Moreover, has any real user of LIO participated in those >> threads? None? > > This isn't a democracy ... it's about choosing the most community > oriented code base so that it's easily maintainable and easy to add > feature requests and improvements as and when they come along. In the > past six months, LIO has made genuine efforts to clean up its act, > streamline its code and support the other community projects that would > need to go above and around it. At first, can you recall any cases where community comments to SCST were not addressed? All of them have been addressed and none ignored. NEVER. Simply, LIO is very much premature code comparing to SCST. It is very easy to find in it simple issues to comment, hence you see the big value of comments. In contrast, SCST has been maturing for many years (since 2004). It's polished to high finish, so you can't so easily find out something to improve in it. The feature requests and improvements in LIO you are referring simply already in SCST. Also, doesn't the size of the community reflects how community oriented project is? So far in the kernel community we see that, basically, the only person, Christoph Hellwig, has taken responsibility to judge and he is pushing LIO. Christoph is a very authoritative person, so many people are just following his direction not dare to object. Nobody wants to go against Christoph Hellwig. At max, people sending me private support e-mails (thanks!) writing that SCST is great and obviously receives very unfair treatment from the kernel maintainers. But Christoph is a biased person. Several years ago he preferred blessing STGT creation instead of already well existing at that moment SCST. Now we know that was a wrong move and SCST was the right way to go. Are we going to repeat that mistake again? > You seem to have spent a lot of the > intervening time arguing with the sysfs maintainer about why you're > right and he's wrong. Well, we are making the best designed and implemented code, right? Aren't arguments part of this process? Anyway, we almost finished a patch with new SCST sysfs interface, which should satisfy Greg KH requirements. Bart several days ago sent proposed new layout and Greg didn't object to it. We will send this patch in several days. Vlad -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
