From: James Bottomley <James.Bottomley@SteelEye.com>
To: Luben Tuikov <luben_tuikov@adaptec.com>
Cc: ltuikov@yahoo.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH 2.6.13 5/14] sas-class: sas_discover.c Discover process (end devices)
Date: Mon, 12 Sep 2005 16:23:10 -0500 [thread overview]
Message-ID: <1126560191.4825.71.camel@mulgrave> (raw)
In-Reply-To: <4325E5AE.1080900@adaptec.com>
On Mon, 2005-09-12 at 16:31 -0400, Luben Tuikov wrote:
> On 09/12/05 13:52, James Bottomley wrote:
> > Well there is this in sas_discover.h:
> >
> > struct scsi_core_mapping {
> > int channel;
> > int id;
> > };
> >
> > struct LU {
> > [...]
> > struct scsi_core_mapping map;
> >
> >
> > so if you use channel, id and scsilun_to_int() (or your SCSI_LUN
> > reimplementation of that) on your LUN structure, you have everything
> > necessary to interface to scsi_scan_target, yes.
> >
> > You have to have this, otherwise you wouldn't be able to use
> > scsi_add_device in sas_scsi_host.c:sas_register_with_scsi().
> >
> > Based on this it does look like your refusal to use scsi_scan_target is
> > based on ideological rather than technical objections.
>
> Hmm, no.
>
> Channel and id are assigned _after_ the device has been scanned for
> LUs. So I cannot just call scsi_scan_target() and say: "here is
> this SCSI Domain device, I know nothing about, other than
> the fact that it has a Target port, scan it".
In your code channel corresponds to an index in the ports array of the
host adapter and hence is known before you do any logical unit scanning.
Id is assigned from a bitmap in the port. You could do that assignment
in sas_discover_end_dev() then you could use scsi_scan_target() in place
of sas_do_lu_discovery(). It would also mitigate your bug below since
now your id is one to one on the end devices rather than the logical
units of the end devices, so each port would support up to 128 end
devices rather than 128 logical units.
> SCSI Core has no representation of a SCSI Target, it has
> an HCIL representation.
>
> > It also looks like you have a bug in your id mapping code: you allocate
> > one id per lun, not per target, so you're going to run out pretty
> > quickly when you meet a device with actual logical units, since you hard
> > code max_ids to 128 in sas_port.c
>
> Yes, this is a bit more involved (on a larger scale than per port).
> The hard coding is intentional.
>
> Ideally, I'd not have to generate Channel and Id to accomodate
> SCSI Core's ancient SPI centric code.
>
> Then I'd not need max_ids and/or the bitmap.
James
next prev parent reply other threads:[~2005-09-12 21:23 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-09 19:40 [PATCH 2.6.13 5/14] sas-class: sas_discover.c Discover process (end devices) Luben Tuikov
2005-09-09 19:59 ` Nish Aravamudan
2005-09-09 20:11 ` Luben Tuikov
2005-09-09 23:25 ` James Bottomley
2005-09-10 2:44 ` Luben Tuikov
2005-09-10 5:39 ` Douglas Gilbert
2005-09-10 16:01 ` James Bottomley
2005-09-12 15:06 ` Luben Tuikov
2005-09-12 16:27 ` Patrick Mansfield
2005-09-12 20:08 ` Luben Tuikov
2005-09-13 9:05 ` Douglas Gilbert
2005-09-13 13:11 ` Luben Tuikov
2005-09-13 22:42 ` Patrick Mansfield
2005-09-14 12:28 ` Luben Tuikov
2005-09-14 17:13 ` Patrick Mansfield
2005-09-14 17:17 ` Luben Tuikov
2005-09-14 18:47 ` James Bottomley
2005-09-14 20:20 ` Luben Tuikov
2005-09-12 17:52 ` James Bottomley
2005-09-12 20:31 ` Luben Tuikov
2005-09-12 21:23 ` James Bottomley [this message]
2005-09-13 12:49 ` Luben Tuikov
2005-09-13 15:54 ` James Bottomley
2005-09-13 20:01 ` Luben Tuikov
2005-09-11 9:46 ` Christoph Hellwig
2005-09-12 6:17 ` Douglas Gilbert
2005-09-12 14:57 ` James Bottomley
2005-09-12 16:45 ` Patrick Mansfield
2005-09-12 17:21 ` James Bottomley
2005-09-12 18:46 ` Patrick Mansfield
2005-09-13 19:22 ` James Bottomley
2005-09-13 20:23 ` Luben Tuikov
2005-09-13 20:36 ` Matthew Wilcox
2005-09-13 21:02 ` Luben Tuikov
2005-09-13 21:37 ` Stefan Richter
2005-09-13 21:54 ` Luben Tuikov
2005-09-13 22:25 ` Patrick Mansfield
2005-09-14 5:22 ` Sergey Panov
2005-09-14 16:28 ` Patrick Mansfield
2005-09-14 12:13 ` Luben Tuikov
2005-09-14 4:57 ` Sergey Panov
2005-09-14 18:43 ` James Bottomley
2005-09-14 20:17 ` Luben Tuikov
2005-09-15 2:04 ` Sergey Panov
2005-09-12 20:20 ` Luben Tuikov
2005-09-12 20:09 ` Luben Tuikov
2005-09-12 19:39 ` Luben Tuikov
2005-09-12 18:17 ` Luben Tuikov
2005-09-13 10:25 ` Christoph Hellwig
2005-09-13 12:47 ` Douglas Gilbert
2005-09-13 14:58 ` Luben Tuikov
2005-09-12 22:39 ` Luben Tuikov
-- strict thread matches above, loose matches on Subject: below --
2005-09-12 19:04 James.Smart
2005-09-12 19:29 ` Patrick Mansfield
2005-09-12 19:53 James.Smart
2005-09-14 0:58 Ravi Anand
2005-09-14 17:46 Ravi Anand
2005-09-16 7:28 Andreas Herrmann
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=1126560191.4825.71.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=ltuikov@yahoo.com \
--cc=luben_tuikov@adaptec.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).