Re: [PATCH 0/8] tcm_loop updates

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

 



On 07/07/2015 02:25 AM, Nicholas A. Bellinger wrote:
> On Tue, 2015-06-23 at 11:05 +0200, Hannes Reinecke wrote:
>> On 06/23/2015 10:29 AM, Nicholas A. Bellinger wrote:
>>> On Fri, 2015-06-19 at 09:13 +0200, Hannes Reinecke wrote:
>>>> On 06/19/2015 08:48 AM, Christoph Hellwig wrote:
>>>>> What's the benefit of the SAS transport class writeout?  I honestly
>>>>> always saw tcm_loop as a simple loopback driver, with the different
>>>>> transport IDs in the PR code as a gimmick.  Note that vhost and
>>>>> xen-blkback copies that style and I did plan to consolidate it
>>>>> in common code.
>>>>>
>>>> The benefit is that tcm_loop will show up in the system as a 'real'
>>>> SAS hba; long-term goal is to simulate SAS multipathing here.
>>>> I was even planning on adding simlated FC infrastructure, too;
>>>> with that we could simulate FC multipathing, too, and our QA would
>>>> be _so_ happy...
>>>>
>>>
>>> Sounds like a reasonable use-case to support for loopback testing.
>>>
>>>> Again, these patches are mainly a collection of patches I've done to
>>>> test various scenarios, in the hope others might find them useful,
>>>> too. So I can easily hold off these patches until you've posted your
>>>> rework.
>>>>
>>>
>>> How different do you expect sas, fc, and iscsi transports to be..?
>>>
>>> Do you think this would this be better served by a simple tcm_loop LLD
>>> specific API for different multipath transports..?
>>>
>> Actually, I would split off the various transport functions into
>> separate files (tcm_loop_sas, tcm_loop_fc, etc), but keep a common
>> tcm_loop module.
>> We can even make transport classes optional by adding an explicit
>> 'sas.XXX' prefix scanning when creating the device similar to what
>> we do with the 'fc.XXX' prefix already.
>> With that we would have a 'sas.XXX', 'fc.XXX', and 'iqn.XXX' WWN
>> which would attach to the respective transport class, and any other
>> WWN (which would be the default) would be getting the standard
>> emulation without any transport class attached.
> 
> I'm open to merging the tcm_loop patches #1-#6 as-is for the sas
> transport pieces, or wait until you've done a large split based on
> transport class types.
> 
> It's really your call how the initial merge should look.
> 
Probably leave out the transport class stuff for now; I kinda like
the idea of having all types of transport classes available for
tcm_loop.
But this is actually not related to the rest of the patchset, so
you can skip those for the time being.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		               zSeries & Storage
hare@xxxxxxx			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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