public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Mike Christie <mikenc@us.ibm.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: 07 Sep 2004 19:34:31 -0400	[thread overview]
Message-ID: <1094600074.2401.234.camel@mulgrave> (raw)
In-Reply-To: <413E38DB.6040408@us.ibm.com>

On Tue, 2004-09-07 at 18:40, Mike Christie wrote:
> > Possibly, but only if the way its handled would be the same on all iscsi
> > initiator drivers.  Otherwise, if it's specific to the driver
> > implementation, it would be in hostdata. 
> 
> Yes, ok. That is what I am striving for. By us hanging things like 
> target name on the target instead of on the scsi device or scsi host 
> will help us conform to other HW iscsi drivers.

You're thinking of the qlogic one?  They have an entire network stack
onboard and they do have resource restrictions per card.  A virtual
driver doesn't.

>   Regardless, you'd still have
> > one host per one of these entities.
> 
> One host per I_T nexus/session? But I thought the only reason against 
> using a single host for all nexii (ignoring the port/channel 
> discussion), was that the driver would need its own refcounting.

It's not just refcounting, it's resource management.  It seems to me,
given that you can allocate resources per connection that per connection
is the most efficient way to manage them.

> If the target has some place for driver target data (with the common 
> iscsi code going in the appropriate transport class stucts) couldn't we 
> just do sometihng similar to how a scsi_device has the hostdata pointers 
> and drivers seem to assume when slave_destroy is called they can just 
> free what was allocated in slave_alloc. And when the driver does its 
> final scsi_host_put it assumes the hostdata will get freed when all the 
> handles are released. If the midlayer could provide any similar lifetime 
> management functionality for targets the iscsi driver would not need any 
> private structures that are refcounted internally since everything could 
> fall under the host, device, or target's managemnet.

Theoretically, I suppose.  The mid-layer really prefers to think in
terms of hosts and devices.  It doesn't really have much use for
targets.

James



  parent reply	other threads:[~2004-09-07 23:37 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
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 [this message]
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=1094600074.2401.234.camel@mulgrave \
    --to=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=mikenc@us.ibm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox