All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Christie <mikenc@us.ibm.com>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Mike Christie <michaelc@cs.wisc.edu>,
	"Scott M. Ferris" <sferris@acm.org>,
	Matthew Wilcox <willy@debian.org>, Christoph Hellwig <hch@lst.de>,
	iscsi -devel <linux-iscsi-devel@lists.sourceforge.net>,
	David Wysochanski <davidw@netapp.com>,
	"Surekha.PC" <surekhap@cisco.com>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs	take 2
Date: Tue, 07 Sep 2004 14:37:27 -0700	[thread overview]
Message-ID: <413E2A17.80107@us.ibm.com> (raw)
In-Reply-To: <1094592818.1716.159.camel@mulgrave>

James Bottomley wrote:

> On Tue, 2004-09-07 at 17:12, Mike Christie wrote:
> 
>>>This is exactly why I ask these questions.  The iSCSI driver
>>>developers just implemented this, because they thought this is what
>>>you and Christoph were asking for.  Apparently it's not what you
>>>wanted.
>>
>>Thank you for clarifying this. So we should go back to a single linux host,
>>right? The iscsi session is an I_T nexus, so the only way to store the
>>session state in the host is to allocate a session per host.
> 
> 
> No; for iscsi, the host and target for I_T is the right thing to do.
> 
> The reason why doesn't lie in terminology or a specification, it lies in
> the code.
> 
> When the cisco-iscsi driver was first presented, it had a single host
> for everything and a huge connection management resource array hanging
> off that.  This was clearly wrong beacuse there was a huge overhead
> managing the array.  The correct approach was to make the host
> correspond to a single element of that array and use the mid-layer host
> management functions instead of home grown resource management
> functions.  Doing it this way makes both the management and presentation
> of the information more logical and the code cleaner.

Ok. If the new magic iscsi transport specific target code handles target 
data like the scsi_host does for hostdata then would it be better to put 
our session struct in the target data? I think this also simplifies 
refcounting. Most session stuff makes sense hanging off the target so 
this might be easier, right?


> James
> 
> 
> 


  reply	other threads:[~2004-09-07 21:43 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <413557CB.8010008@cs.wisc.edu>
     [not found] ` <20040901162042.GC26753@null.msp.redhat.com>
2004-09-06 14:32   ` [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2 Christoph Hellwig
2004-09-06 16:33     ` Matthew Wilcox
2004-09-06 18:15       ` Mike Christie
2004-09-06 18:54         ` Mike Christie
2004-09-06 22:48           ` Mike Christie
2004-09-06 23:11             ` James Bottomley
2004-09-07  2:46               ` Mike Christie
2004-09-07 15:35                 ` James Bottomley
2004-09-07 19:19                   ` Scott M. Ferris
2004-09-07 20:42                     ` James Bottomley
2004-09-07 21:05                       ` Scott M. Ferris
2004-09-07 21:12                         ` Mike Christie
2004-09-07 21:24                           ` Scott M. Ferris
2004-09-07 21:33                           ` James Bottomley
2004-09-07 21:37                             ` Mike Christie [this message]
2004-09-07 22:05                               ` James Bottomley
2004-09-07 22:40                                 ` Mike Christie
2004-09-07 22:57                                   ` Mike Christie
2004-09-08 10:27                                     ` Mike Christie
2004-09-07 23:34                                   ` James Bottomley
2004-09-08  9:19                                     ` Mike Christie
2004-09-08 14:53                                       ` James Bottomley
2004-09-07 21:14                         ` James Bottomley
2004-09-08  2:33                         ` Douglas Gilbert
2004-09-08 14:38                           ` Randy.Dunlap
2004-09-08 18:11                             ` Bryan Henderson
2004-09-09  0:40                             ` Douglas Gilbert
2004-09-09 15:40                               ` AJ Lewis
2004-09-07 15:24         ` AJ Lewis

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=413E2A17.80107@us.ibm.com \
    --to=mikenc@us.ibm.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=davidw@netapp.com \
    --cc=hch@lst.de \
    --cc=linux-iscsi-devel@lists.sourceforge.net \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michaelc@cs.wisc.edu \
    --cc=sferris@acm.org \
    --cc=surekhap@cisco.com \
    --cc=willy@debian.org \
    /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.