On Monday, December 29, 2003 9:33 AM, James Bottomley wrote:
> On Fri, 2003-12-05 at 19:15, Andrew Vasquez wrote:
> > False start. I've uploaded 8.00.00b8 to the SF site. This driver
> > instructs the mid-layer to perform its initial scan with
> > scsi_scan_host(). During testing, I disable the scan. Sorry for
> > the confusion.
>
> OK, I've begun the BK process again.
>
> This driver is now in BK at
>
> bk://linux-scsi.bkbits.net/scsi-qla2xxx-2.6
>
> I didn't see any comments about Christoph's patches, so is it OK if I
> apply them?
>
Yes, I've been entrenched in several side projects. I have a beta 9
ready for release which includes Christoph's patches as well as a
couple of other changes as a result of his comments (qla_fo.cfg,
exioct.h dependencies). At this time though, I need to wait to
release until I receive another firmware drop.
> I plan to let it mature in it's own tree for a short while with the
> object being to get it into the right shape for a 2.6 inclusion
> candidate.
>
> The two items we still need to do something about are:
>
> - Multi Pathing. This really doesn't belong in the kernel
>
Yes, given the structure and form of recent patches, that certainly
does seem to be the case - which from QLogic's standpoint (now) seems
to be the proper path. Just for clarification, given the structure of
the driver now (failover completely separated), inclusion of the
qla2xxx driver would exclude the following failover files:
qla_fo.c qla_foln.c qla_cfg.c qla_cfgln.c
correct?
> - The odd ioctl set to the qla device...I'd much rather see something
> more standard that all FC drivers can use.
>
Are you proposing to standardize a transport by which a user-space
application communicates with a driver (beyond IOCTLs), or, are you
suggesting there be some commonality in functional interfaces (i.e.
SNIA) for all FC drivers?
Look, IOCTLs were mainly used and built upon due the platform agnostic
nature of the interface. All QLogic drivers (Linux, Solaris, Windows,
and Netware), use the platform's IOCTL interface with the QLogic
specific EXIOCT interfaces to pass information to/from user and driver
space. Several user-space APIs were then created which use the EXIOCT
interface, SNIA (or HBAAPI), and several internal APIs, which are
ultimately used by all QLogic applications.
--
Andrew Vasquez
On Thu, Jan 08, 2004 at 08:47:51AM -0800, Andrew Vasquez wrote:
> Yes, given the structure and form of recent patches, that certainly
> does seem to be the case - which from QLogic's standpoint (now) seems
> to be the proper path. Just for clarification, given the structure of
> the driver now (failover completely separated), inclusion of the
> qla2xxx driver would exclude the following failover files:
>
> qla_fo.c qla_foln.c qla_cfg.c qla_cfgln.c
>
> correct?
+ qla_inioct.c qla_xioct.c
and the associated headers for both the ioctl and failover code, of course
> > - The odd ioctl set to the qla device...I'd much rather see something
> > more standard that all FC drivers can use.
> >
>
> Are you proposing to standardize a transport by which a user-space
> application communicates with a driver (beyond IOCTLs), or, are you
> suggesting there be some commonality in functional interfaces (i.e.
> SNIA) for all FC drivers?
the SNIA HBA-API spec is completely broken. But we should try to support
a sanitized subset of the spec using the transport class work that's
currently discussed on linux-scsi.
Christoph Hellwig [[email protected]] wrote:
> the SNIA HBA-API spec is completely broken. But we should try to support
> a sanitized subset of the spec using the transport class work that's
> currently discussed on linux-scsi.
>
This sounds good. It would seem that HBA API adapter and port
information through sysfs (libsysfs) should be doable through the
transport class. Also some partial information of the other hba api
functions could be supported though other sysfs attributes but the sends
would still need to use the old interface.
-andmike
--
Michael Anderson
[email protected]
On Thu, Jan 08, 2004 at 11:33:36AM -0800, Mike Anderson wrote:
> This sounds good. It would seem that HBA API adapter and port
> information through sysfs (libsysfs) should be doable through the
> transport class.
Yes.
> Also some partial information of the other hba api
> functions could be supported though other sysfs attributes but the sends
> would still need to use the old interface.
With sends are you referring to function that support certain scsi
commands like report luns and report capacity? We have a perfectly
fine interface for that and it's SG_IO..
Christoph Hellwig [[email protected]] wrote:
> > Also some partial information of the other hba api
> > functions could be supported though other sysfs attributes but the sends
> > would still need to use the old interface.
>
> With sends are you referring to function that support certain scsi
> commands like report luns and report capacity? We have a perfectly
> fine interface for that and it's SG_IO..
I was thinking about the fabric management functions section of the
spec. I would believe that the SG_IO should be able to handle the SCSI
information functions section (though I have used this interface very
little).
-andmike
--
Michael Anderson
[email protected]
On Thu, Jan 08, 2004 at 11:57:32AM -0800, Mike Anderson wrote:
> > With sends are you referring to function that support certain scsi
> > commands like report luns and report capacity? We have a perfectly
> > fine interface for that and it's SG_IO..
>
> I was thinking about the fabric management functions section of the
> spec.
Hmm, I don't remember those in the copy I have. It appears there's
a V2 of the spec on the SNIA server now and I'll take a look at
what they are supposed to do.
Christoph Hellwig [[email protected]] wrote:
> On Thu, Jan 08, 2004 at 11:57:32AM -0800, Mike Anderson wrote:
> > > With sends are you referring to function that support certain scsi
> > > commands like report luns and report capacity? We have a perfectly
> > > fine interface for that and it's SG_IO..
> >
> > I was thinking about the fabric management functions section of the
> > spec.
>
> Hmm, I don't remember those in the copy I have. It appears there's
> a V2 of the spec on the SNIA server now and I'll take a look at
> what they are supposed to do.
Yes, I guess I should have mentioned that I was looking at v2.18 from
T11 (02-149v0.pdf).
-andmike
--
Michael Anderson
[email protected]