linux-kernel - Re: [PATCH 5/6] firewire: SBP-2 highlevel driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <463B1716.60108@s5r6.in-berlin.de>
Date:	Fri, 04 May 2007 13:20:54 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Christoph Hellwig <hch@...radead.org>
CC:	linux-kernel@...r.kernel.org, Kristian H??gsberg <krh@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux1394-devel <linux1394-devel@...ts.sourceforge.net>,
	jejb@...eleye.com
Subject: Re: [PATCH 5/6] firewire: SBP-2 highlevel driver

Christoph Hellwig wrote:
>> >> +	sd->scsi_host->hostdata[0] = (unsigned long)unit;
...
> scsi_host_alloc
> is designed to allocate space for your private data aswell.  So you
> should call it early on an allocate the sbp2_device as part of the Scsi_Host
> instead of just stuffing in a pointer.

Aha, OK.

As long as we have 1 SBP-2 target LU == 1 instance of struct Scsi_Host,
the usage of ->hostdata as backpointer to an fw_unit is appropriate
though.  The lifetime of the fw_unit starts before and ends after that
of the Scsi_Host.  Of course if we reorganize this to use Scsi_Host more
as a representation of an SBP-2 initiator port (or for all our initiator
ports at once), some oddities like this ->hostdata usage will go away.

>> > The discovery of LUs of SBP-2 targets happens on the IEEE 1212
>> > level of things.
[...]
> Okay, so sbp2 decided to be non-standard here, what a pity.

Well, SBP-2 (the spec) is from the earlier days when the SCSI
Architecture Model was young and there didn't exist that many other SCSI
transports/interconnects besides SCSI Parallel Interconnect.  And for
better or worse, SBP-3 inherited this part of SBP-2's specialties.

> It's probably better to use scsi_scan_target with a specific lun,
> though as scsi_add_device is a rather awkward API.

Looking into these things were on my long-term agenda for mainline's
sbp2 driver anyway.  My plans just got dragged out when I expanded my
activities from ieee1394/sbp2 to ieee1394/.  As far as fw-sbp2 is
concerned, I don't know if these issues (which it merely took over from
sbp2) need to be addressed before integration into mainline.  fw-sbp2 is
something in the middle between a new submission and a gradual update.

Do you see the TODOs related to integration with the SCSI stack (which
apply to sbp2 as well) as blocking for fw-sbp2?

Thanks for looking into it and for all the advice,
-- 
Stefan Richter
-=====-=-=== -=-= --=--
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/