Date:	Tue, 31 Aug 2010 00:47:10 +0400
From:	Vladislav Bolkhovitin <vst@...b.net>
To:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
CC:	James Bottomley <James.Bottomley@...e.de>,
	Dirk Meister <dmeister@...-paderborn.de>,
	linux-scsi@...r.kernel.org, Chetan Loke <chetanloke@...il.com>,
	Chetan Loke <generationgnu@...oo.com>,
	scst-devel <scst-devel@...ts.sourceforge.net>,
	linux-kernel@...r.kernel.org, Mike Christie <michaelc@...wisc.edu>,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Subject: Re: [Scst-devel] Fwd: Re: linuxcon 2010...

Nicholas A. Bellinger, on 08/29/2010 12:47 AM wrote:
>>>>> As mentioned explictly earlier in this thread, my WIP code for the
>>>>> kernel level subsystem backstore using STGT kernel<->    user CDB
>>>>> passthrough logic in drivers/target/target_core_stgt.c is a item on
>>>>> my TODO list, but I will repeat, is NOT being tagged as a mainline
>>>>> .37 item.
>>>>
>>>> Hmm, I can't understand, if target_core_stgt.c is "NOT being tagged as a
>>>> mainline .37 item", then the STGT ABI compatibility for being a drop in
>>>> replacement for STGT isn't a requirement? Or am I missing something?
>>>
>>> Sorry, but I have no idea what you are trying to conjour up here.
>>>
>>> To spell out (again) the TCM/LIO<->STGT compatibility stages that have
>>> been persued pubically over the last months:
>>>
>>> I) Create proper userspace tgt.git SG_IO and BSG passthrough into
>>>      TCM_Loop v4 using high-level multi-fabric WWPN emulation so that TCM
>>>      Core SPC-4 kernel emulation is exposed to STGT user fabrics, eg:
>>>      userspace fabric module ->   kernel backstore passthrough.  (DONE
>>>      for .37, and STGT passthrough + BSG backstore support merged into
>>>      tgt.git by Tomo-san)
>>>
>>> II) Complete target_core_stgt.c TCM subsystem plugin for kernel ->   user
>>>       CDB ->   LUN passthrough building upon existing
>>>       drivers/scsi/scsi_tgt_*.c code.  (WIP for .38, made available
>>>       initially as a seperate standalone .ko module in lio-core-2.6.git)
>>
>> That would mean that if LIO merged in .37:
>>
>> 1. It would be merged _without_ STGT ABI compatibility, i.e. one of the
>> requirements for a new SCSI target infrastructure merge is violated.
>>
>
> Sorry, but you are completely wrong here.  This has nothing to do with a
> question of STGT kernel 'ABI compatibility' (because there is only one
> mainline user!), but has everything to do with being able to expose TCM
> kernel level SPC-4 emulation, and make this logic available to existing
> userspace fabrics in tgt.git.  Again, we are talking about userspace
> STGT fabric module<->  TCM kernel backstore support for .37, which has
> already been merged by into tgt.git, and being used by other STGT users
> for SG_IO and BSG passthrough.

You are proving that I'm actually right ;). In the beginning of this 
thread I offered a transition path from STGT to SCST and James rejected 
it, because it didn't confirm a requirement that a new SCSI target 
infrastructure must be STGT ABI compatible. But latter James left this 
decision up to the STGT developers and now you are confirming that they 
don't see any ABI compatibility issues, so my transition path fully 
confirms all the requirements.

>> 2. It would _not_ be a drop in replacement for STGT, because STGT's
>> drivers/scsi/scsi_tgt_*.c code would stay in the kernel. Those would
>> effectively mean that another requirement for a new SCSI target
>> infrastructure merge would be violated: there would be 2 SCSI target
>> infrastructures in the kernel and any STGT in-kernel driver (for
>> instance, built as an outside module) would continue working. My
>> understanding of "drop in replacement" is "one out, another in at once".
>
> Sorry, but this is just more generic handwaving on your part.  What
> constitutes a 'drop in replacement' for STGT is a decision that was to
> be made by the STGT developers, not by you.  target_core_stgt.c is an
> extraordinarly transparent method of bringing drivers/scsi/scsi_tgt_*
> logic into the TCM Core HBA/DEV design, and allows us to build upon and
> improve the existing mainline kernel code.

I'm not deciding anything, I'm only analyzing and seeing a contradiction:

1. James wants only one SCSI target infrastructure in the kernel.

2. If drivers/scsi/scsi_tgt_*.c left after the merge of the new SCSI 
target infrastructure, it would mean that STGT left as well => 2 SCSI 
target infrastructure in the kernel.

For me it doesn't matter. I just want clear rules, hence asking for 
clarification.

> It is obvious to even an casual observer from watching the TCM/LIO patch
> series that have been flying across the linux-scsi wire the last 24
> months that the major features (including PR and ALUA, and new fabric
> module drivers) have been developed individual feature bit by feature
> bit using a distributed git workflow in a bisectable manner.  Each
> series was produced in such a manner that each patch could be reviewed
> individually by those interested parties.

That's a nice, but quite meaningless LIO advertisement. SCST is using 
the same bisectable, distributed and reviewable workflow. If we had a 
kernel.org git account, we would use it as well, but so far we are happy 
with SF.net hosting. BTW, how was you able to get the git account 
without a single patch merged in the kernel? You must have good 
connections in the kernel community.

> This is the big difference between our respective development processes.
> This is the case not only for SCSI feature bits that TCM/LIO and SCST
> share, but for features in TCM/LIO v4 that are unique and not available
> in any other target implemention, anywhere.  And yes, I am most
> certainly talking about code beyond just the SCSI level fabric emulation
> bits you are mentioning above.

Can you list us benefits for an average user of that work?

>> But all my attempts to explain my view are just blindly
>> ignored without any considerations, so I have no idea how more I can
>> explain it.
>>
>
> Then I suggest you learn a better way of communicating your ideas if you
> really want to work with members of the LIO/STGT development
> communities.
>
> First, I suggest you start explaining your ideas with actual kernel code
> that is 1) human readable and 2) presented in such a manner that makes
> it accessable for others with skills possibly different (and greater)
> than your own to review and give feedback.

I have sent patches twice, the second time few months ago. Weren't they 
human readable and accessible for kernel developers who are experts in 
dealing with sent by e-mail patches?

Thanks,
Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists