Re: [Scst-devel] How hard would it be to merge the QLogic driver for the QLE2462 with the scst target driver?

[Vladislav B. <vs...@vl...>]

Matthew Jacob wrote:
>> 1. It is a cross platform and self-containing, so it needs a major cleanup.
> 
> It has been cross-platform *and* cross chip (supporting parallel SCSI
> as well) and that has been one of its strengths. However, it is no
> longer being actively maintained as such by me. I no longer am a
> committer with FreeBSD or OpenBSD and only am a committer of very low
> frequency with NetBSD. All of the other consumers of it that used it
> in initiator mode are pushing up daisies.
> 
> It has had a very long history, starting in 1997 as part of the NetBSD
> Alpha TurboLaser port at NASA/Ames research center. That was over ten
> years ago, and that's a very long time for a basic driver design to
> hang around.
> 
> The target mode stuff still lives on in a number of places, but I
> haven't had any paying work on it for a while and sure am really
> really tired of it. If it helped generate income, I get more
> interested. Otherwise, my love for it has waned.
> 
> One could do a major rewrite of it- and dump the parallel SCSI
> support- but given the current state of Fibre Channel and the likely
> course of transport layers over the next 5-10 years, it doesn't seem
> that the effort would be worth it.
> 
> 
>> Particularly, all not current Linux specific pieces of code should be
>> removed and firmware loader should be changed to load external firmware, not
>> internal, because this is in-kernel requirement.
> 
> Actually, external firmware loading has been around for a while in this driver.
> 
>> 2. It duplicates many things that the mainline qla2xxx driver and SCSI
>> initiator mid-layer do and that code should be either removed or rewritten
>> to use common facilities. Particularly, I don't see in it support for
>> initiator mode, since for it already there is qla2xxx driver. As a direct
>> consequence, there would be problems to use initiator and target ports
>> simultaneously.
> 
> Unless you do device slot exclusion. This particular issue has come up
> over and over again- not necessarily because the qla_isp is bad as an
> initiator driver-

I've never written the driver is bad. In fact, I think, it's quite good.

> it's more that customers wanted to "leverage" the
> testing that a stock kernel and stock qla2xxx driver receives. At at
> least 3 different companies we put in some mechanism in place to allow
> both drivers to not step on each other/
> 
> 
>> Thus, seems the best way would be to move the 24xx specific bits from
>> qla_isp to qla2x00t, because qla2x00t doesn't have the above shortcomings
>> and more or less mainline ready.
> 
> Frankly, the best thing to do is to take the driver that is in the
> mainline tree and (regen) patches to it that allow it to be target
> mode capable. That driver is being actively maintained by the vendor
> (with some fuzz over what 'active' means), but the vendor doesn't want
> to take on target mode support.

This is pretty much what I meant. Driver qla2x00t is an add-on for 
qla2xxx with a small patch adding necessary hooks in qla2xxx. In the 
ultimate case qla2x00t files can be made a part of drivers/scsi/qla2xxx.