On Mon, Aug 23, 2010 at 7:58 PM, James Bottomley <James.Bottomley@xxxxxxx> wrote: > On Mon, 2010-08-23 at 19:44 +0200, Bart Van Assche wrote: >> On Mon, Aug 23, 2010 at 6:59 PM, James Bottomley >> <James.Bottomley@xxxxxxx> wrote: >> > >> > My basic conclusion was that there's no incredible discriminator between >> > LIO and STGT (although there are reams written on which performs better >> > in which circumsances, is useful for clustering, supports ALUA, etc. >> > each with partisans for the features). If the two communities can't >> > work together (as seems to be the case) and I have to choose one, I'll >> > go by what helps me which, as I've said before, are: >> > >> > 1. That it would be a drop in replacement for STGT (our current >> > in-kernel target mode driver), since he only wanted a single >> > SCSI target infrastructure. >> > >> > 2. That it used a modern sysfs based control and configuration >> > plane. >> > >> > 3. That the code was reviewed as clean enough for inclusion. Let us return to the three acceptance criteria. At this time none of the existing kernel-based target frameworks support ibmvstgt and hence none of them satisfy criterion [1]. Yet these criteria have been used to decide that one kernel-based target framework will be accepted and that the other will not be accepted. I'm afraid that I missed something ? Also, you write that you, as a kernel maintainer, might become in a position that you have to choose a target framework. I would appreciate it if you would take the time to reread the document Documentation/ManagementStyle. This document was written by Linus Torvalds and explains that a kernel maintainer should try to avoid having to take such decisions. The whole first chapter of that document is devoted to this subject. I regret that you got involved personally in this discussion. It would have been a lot easier for everyone if you would have been able to keep a neutral position. Bart. -- 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
