Re: [PATCH 2.6.13 5/14] sas-class: sas_discover.c Discover process (end devices)

[James Bottomley <James.Bottomley@SteelEye.com>]

On Tue, 2005-09-13 at 08:49 -0400, Luben Tuikov wrote:
> >>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.
> 
> James, even Christoph understands this: no HCIL in SCSI Core is needed.
> The whole problem is not what you *keep grinding about over and over above*,
> but the fact that I have to _invent_ channel, id and emaciated LUN to give
> to the broken, outdated and Parallel SCSI-centric SCSI Core.
> 
> Christoph understand this, why cannot you?
> 
> That bitmap was added in the last moment when I needed to register devices
> with SCSI Core.  There is a lot of other problems which I've pointed out
> int the scsi glue file, which do you not want to talk about or you do
> not bring up.

I think, therefore, I've made the point that you could have used
scsi_scan_target() but chose not to for ideological rather than
technical reasons.

Writing code which duplicates existing mid-layer functionality is what
I've been telling you all along isn't acceptable.  Use what exists to
day and if it doesn't work quite right, fix it.  If you want to alter an
interface, we need to evolve towards it keeping all the current users
working.

Now, I can merge your transport class with Christoph's (or find someone
else to do it for me) by converting it to use the existing mid-layer and
transport class infrastructure (I think, actually, it will look rather
nice after this and probably reduce in size by about 50%) but I'd much
rather that you did it.

The unified transport class should be capable of supporting both the
aic94xx SAS card using your existing domain device interface as well as
the fusion SAS card, which is the whole goal of all of this in the first
place.

So, do you want to do this work, or would you rather just be responsible
for the aic94xx driver?

James


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/