All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Markus Lidel <Markus.Lidel@shadowconnect.com>,
	Christoph Hellwig <hch@infradead.org>,
	Warren Togami <wtogami@redhat.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Merge I2O patches from -mm
Date: Tue, 17 Aug 2004 16:06:21 +0100	[thread overview]
Message-ID: <20040817160621.A22892@infradead.org> (raw)
In-Reply-To: <1092751257.22793.8.camel@localhost.localdomain>; from alan@lxorguk.ukuu.org.uk on Tue, Aug 17, 2004 at 03:00:59PM +0100

On Tue, Aug 17, 2004 at 03:00:59PM +0100, Alan Cox wrote:
> On Maw, 2004-08-17 at 14:31, Markus Lidel wrote:
> > > Now to i2o_scsi:
> > >  - the logic of "demand-allocating" Scsi_Hosts looks rather bad to me,
> > >    life would be much simpler with a Scsi_Host per i2o device.
> > 
> > But wouldn't it be a waste of resources to allocate a Scsi_Host 
> > structure for every I2O device? Note that the i2o_scsi "sees" all disks 
> > even if they are in a RAID array, so in most cases there are at least 3 
> > Scsi_Host adapters...
> 
> Christoph the "I2O" device is a communication processor. You need to
> preserve the real scsi busses in order to get sane results from scsi
> tools. If EH is implemented you'll need this to do controlled resets
> (although this gets quite umm 'interesting' if using i2o_block also)

Okay, then we'll have to rething the data structures a little more.
I was under the impression the scsi busses were completely faked for
the OS.


  reply	other threads:[~2004-08-17 15:06 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-15 10:15 Merge I2O patches from -mm Warren Togami
2004-08-17  2:15 ` Andrew Morton
2004-08-17  8:36   ` Markus Lidel
2004-08-17 11:53 ` Christoph Hellwig
2004-08-17 13:31   ` Markus Lidel
2004-08-17 14:00     ` Alan Cox
2004-08-17 15:06       ` Christoph Hellwig [this message]
2004-08-17 14:50         ` Alan Cox
2004-08-17 15:17     ` Christoph Hellwig
2004-08-17 17:05       ` Markus Lidel
2004-08-17 16:56     ` Christoph Hellwig
2004-08-17 18:37       ` Markus Lidel
  -- strict thread matches above, loose matches on Subject: below --
2004-08-18 23:08 Markus Lidel
2004-08-18 23:24 ` Christoph Hellwig
2004-08-18 23:33   ` Markus Lidel
2004-08-19  9:48     ` Christoph Hellwig
2004-08-19 10:16       ` Markus Lidel
2004-08-19 10:06         ` Christoph Hellwig
2004-08-19 11:54           ` Markus Lidel
2004-08-23 17:55             ` Christoph Hellwig
2004-08-24  8:16               ` Markus Lidel
2004-08-24 12:45                 ` Christoph Hellwig
2004-08-24 16:00                   ` Markus Lidel
2004-08-28 10:13                     ` Warren Togami

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=20040817160621.A22892@infradead.org \
    --to=hch@infradead.org \
    --cc=Markus.Lidel@shadowconnect.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wtogami@redhat.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.