On Tue, Jan 11, 2005 at 01:34:37PM -0500, [EMAIL PROTECTED] wrote:
> Christoph and Community,
>
> The 8.0.20 release of the Emulex driver has been recently posted
> to SourceForge:
> http://prdownloads.sourceforge.net/lpfcxxxx/lpfcdriver-2.6-8.0.20.tar.gz?download
>
>
> Emulex has been working hard to complete the outstanding items for upstream
> acceptance:
>
> - Streamline I/O submission path.
> - Removal of GFP_ATOMIC allocations in I/O path. Consider locations
> as well.
> - Movement of Consistent Bindings to the FC Transport.
> - Discovery changes:
> Target discovery via scsi_scan_single_target. Reduce bookkeeping
> in lpfc_find_target().
> Cleanse target removal. Ensure no more __devices references.
> - Removal of ifdefs for older kernel support and different patches
>
> And from our point of view :
> - Add management interfaces in support of HBAAPI.
I started to look through it, here's some thing I found so far:
o there's still a ->proc_info method which we don't want for new drivers
o the host removal is still quite hackish and probably racy:
- everything what's you're ding with FC_UNLOADING should be done in
the midlayer where we already have a state machine for the
Scsi_Host
- target removal shouldn't happen from your remove method but via
scsi_remove_host
o the driver would benefit a _lot_ from driver private data in
scsi_target, I think we should do that and basically get rid of
phba->device_queue_hash
o what about lpfc_target->rport? This should probably better be in
the fc_target structure, no?
o lpfc_target vs lpfc_nodelist. I'd see these merged into a single
structure. In fact large parts of lpfc_nodelist should probably
move into the transport class.
o the memory allocation for non-I/O path stilled looked total overkill
to me, but it seems you're doing an awfull lot from the interrupt handler
still. Wouldn't it be easier to do much of it from process context
via the kernel thread?
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
