Re: [Scst-devel] Fwd: Re: linuxcon 2010...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Nicholas A. Bellinger, on 08/27/2010 01:23 AM wrote:
Nicholas A. Bellinger, on 08/25/2010 01:23 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.

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".

Please tell me where I'm wrong? I would appreciate if you be precise and answer the above 2 my concerns. There is no point to again repeat what you have already written without adding any new information.

Tomo-san, mnc, and other storage folks have been briefed on the
remaining issues that would be involved to get a prototype
functioning with drivers/target/target_core_stgt.c, and rough idea of
what it would take in existing mainline drivers/scsi/scsi_tgt_*.c
code.  With the current WIP code this will allow the userspace CDB ->
LUN passthrough to function transparently with all TCM SPC-4
compliant logic as a standalone struct se_subsystem_api
tcm_core_stgt.ko backstore.

This is exactly what we are discussing.

Then I suggest you start working on a patch for drivers/scsi/scsi_tgt_*
in order to address what you believe are the preceived shortcomings of
the original design.

Until you can do that, and actually take an impartial look at the
existing drivers/scsi/scsi_tgt_*.c,  it would be a bit difficult to
beleive you genuinely want to steer our current level of interaction
away from continued hand-waving noise into a real rational technical
discourse between yourself and the LIO/STGT development community.

My look is completely impartial. With all my respect, I'm just quite ahead of you and can see what you are unable (or don't want?) to see. I did what you are currently doing almost 4 years ago. I have already written all the necessary code and addressed all _rose on practice_ concerns. 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.

Thanks,
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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux