From: Mike Christie <mikenc@us.ibm.com>
To: Mike Christie <michaelc@cs.wisc.edu>
Cc: "Surekha.PC" <surekhap@cisco.com>,
'SCSI Mailing List' <linux-scsi@vger.kernel.org>,
linux-iscsi-devel@lists.sourceforge.net
Subject: Re: [PATCH][RFC] iSCSI transport class
Date: Mon, 05 Apr 2004 14:10:15 -0700 [thread overview]
Message-ID: <4071CB37.7070401@us.ibm.com> (raw)
In-Reply-To: <4071BFFF.5090405@cs.wisc.edu>
Mike Christie wrote:
> Hey,
>
> Surekha.PC wrote:
>
>> Hi Mike,
>>
>> Sorry for the delay.
>> The structure which I represented was meant to have iSCSI transport
>> attributes
>> under their respective category. Right now, in our iSCSI driver all
>> attributes are defined
>> in `iscsi-attr.c` and `iscsi-debug-attr.c` which need to be either
>> per lun
>> or per target.
>>
>>>> I have reviewed your changes for iSCSI transport class.
>>>
>>>
>>> The changes
>>>
>>>> look fine. I have few suggestions on further improvements. The
>>>> attributes can be organised
>>>> under iSCSI transport class in the following structure.
>>>>
>>>> # ls /sys/class/iscsi_transport/*
>>>>
>>>> /* iSCSI host specific attributes */
>>>> |-- shutdown
>>>> |-- host_id
>>>> |-- ....
>>>
>>>
>>> The examples you placed here are not tranport specific. They are just
>>> HBA values, and should stay under the host attributes.
>>
>>
>>
>> AFAIU Transport class is basically to hold all private attributes of the
>> iSCSI driver.
>
>
> That is wrong. Look at the qla2xxx or 53c700 driver. The transport
> classes represent transport specifics. They are not there for a
> driver that is a particular transport to place all its attributes, and
> each driver that is a particular transport does not implement its
> own class.
Let me clarify what I wrote. I am just saying becuase Cisco's software
iscsi driver has some attribute which a fc or spi or whatever driver
lacks does not necessarily mean it is transport related. Some of your
attributes are HBA or device related, and some are a result of your
implmentation, and some are iscsi related.
>> Since iSCSI driver has attributes which are hba/target/lun specific it
>> would
>> be good to have them in a place away from the generic scsi attributes.
>> For eg, the "shutdown" attribute is a iSCSI attribute to shutdown the
>> iSCSI
>> hba.
>
>
> shutdown is a hba thing, and has nothing to do with iscsi itself.
>
>> Similarly host_id is iSCSI transport specific and gives the host number.
>
>
> How is the struct scsi_host's host_no related to the transport?
> It is assigned from the SCSI layer.
>
>>> Also, the host layout here does not look right. What happens when I
>>> have multiple HBAs?
>>
>>
>> Right now iSCSI driver supports single HBA, hence this representation
>> is OK.
>> However in multiple HBA case, it can be represented as below.
>
>
> Again, only specific to your driver.
>
>> /sys/class/iscsi_transport/
>> |--host1/
>> |-- shutdown_hba
>> |-- show_hba_id
>> |--host2/
>> |-- ---"----
>> |-- ---"----
>>
>>
>>
>>>> /* iSCSI target specific attributes */
>>>> |-- 1:0:1/
>>>> |-- target_addr
>>>> |-- target_name
>>>> |-- target_port
>>>> |-- ....
>>>
>>>
>>> I agree these would be nice under a target attribute. Did
>>> you have something to post since the last time we talked,
>>> or did you write the example by hand?
>>
>>
>>
>> I have written the example by hand, I am working towards implementing it.
>>
>>>> /* lun specific attributes */
>>>> |-- 1:0:1:0/
>>>> |-- device -> ../../../devices/platform/iscsi/1:0:0:0
>>>> |-- driver -> ../../../bus/scsi/drivers/sd
>>>> |-- lun_status
>>>> |-- ....
>>>
>>>
>>> I don't think anything in lun_status is iscsi specific.
>>
>>
>>
>> We have lun specific attributes defined in iSCSI driver some of which
>> can be
>> used in debug mode for testing purposes e.g initiate command timeout on a
>> lun, set lun queue as busy, query the lun status etc.
>> I think since they are private to iSCSI, this is the right place holder.
>
>
> Again, specific to your particular iscsi driver vs transport.
Just another clarification. I am not saying everying you are doing at
the lun level is not iscsi specific.
next prev parent reply other threads:[~2004-04-05 21:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-26 20:50 [PATCH][RFC] iSCSI transport class Mike Christie
2004-03-30 14:21 ` Surekha.PC
2004-03-30 21:02 ` Mike Christie
2004-04-05 13:09 ` Surekha.PC
2004-04-05 20:22 ` Mike Christie
2004-04-05 21:10 ` Mike Christie [this message]
2004-04-06 8:36 ` Heiko Carstens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4071CB37.7070401@us.ibm.com \
--to=mikenc@us.ibm.com \
--cc=linux-iscsi-devel@lists.sourceforge.net \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.edu \
--cc=surekhap@cisco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.