linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* RE: [Announce] Emulex lpfcdriver v8.0.12 available
@ 2004-10-18 21:34 James.Smart
  0 siblings, 0 replies; 10+ messages in thread
From: James.Smart @ 2004-10-18 21:34 UTC (permalink / raw)
  To: hch; +Cc: linux-scsi

> And why should userspace mess with the adapter anyway?  The 
> older drivers
> seem to work very well without that interface.  Also note 
> that due to this
> interfasce you added really horrible helper functions in the driver.

During normal operation - you are correct.

However, all maintenance is done via userspace. There's a lot more to making a supportable product than just the driver. Are you dictating a management scheme where all maintenance/troubleshooting must be done with the driver  detached/unloaded ?

I agree it's not pretty...

> If you want this in find a portable and non-broken interface 
> together with
> the qlogic, lsi and ibm people.

That is exactly the plan - this was an early prototype of what could be turned into a proposal for this effort.

-- James S

^ permalink raw reply	[flat|nested] 10+ messages in thread
* RE: [Announce] Emulex lpfcdriver v8.0.12 available
@ 2004-10-16 21:50 James.Smart
  2004-10-18 20:55 ` Christoph Hellwig
  0 siblings, 1 reply; 10+ messages in thread
From: James.Smart @ 2004-10-16 21:50 UTC (permalink / raw)
  To: hch; +Cc: linux-scsi

We're completing our 8.0.13 release and need to address your comments on binary sysfs attributes

> I don't like many of the binary attributes at all.  As a 
> general rule of thumb never ever use a binary sysfs
> attribute unless it's passed through to the hardware.

There are 5 binary attributes:
- Statistics:
This is replaced by the proposed fc transport patch sent out this week. It will be replaced by the functions supporting the patch.

- slimreg, ctlrreg, and mbox: 
 > For slimreg and ctlreg that is true, but I wonder whether 
 > they're needed at all.  Check how recent X servers access mmio space.
As mentioned, these should meet your definition and be fine. You asked whether they are needed at all. Given that these are the heart of the adapter message passing interface, and used extensively by the driver - having the user space application use them without the coordination of the driver is asking for trouble. Minimally, the driver's lock over the registers/memory needs to be involved. In some cases, the driver remaps these areas away from pci memory and into driver-allocated dma-mapped memory. The application would have no clue where to locate these.  These should stay as is.  It is through these interfaces that diagnostics, firmware loading, and the like take place.

- sendrnid and ctpass:
 > The sendrnid and ctpass ones looks extremly fishy, it's 
 > certainly not a single value that's read/written, and it's
 > deeply magic (and btw, current->pid is not uniqueue in a
 > multithreaded enviroment)
These are used to have the application (usually a storage management suite) interact with FC fabrics - performing requests of nameservers, querying for additional node id information, etc. The use is typically to build topology maps of the FC fabric and the devices attached. Given the payload gets converted into a request to the firmware, it does get posted to the hardware. We do need to find a unique identifier to associate with the thread issuing the request - if for nothing else to associate the responses to the right request as this must be a multi-step function (minimally - write of request, read of response). We could single-thread this so that only one request is outstanding. In this case, the unique id could enforce the single outstanding request. Otherwise it's a voluntary function (e.g. only do the read if your write didn't get rejected). These will be pushed into the fc transp
 ort as host functions in a later patch - so it's function will be fully described/open. One thing we will need to work on is allowing >4k payloads.  Comments ? Issues ? If there is a better way to inject non-FCP FC traffic onto a link, please tell me.

-- James S



^ permalink raw reply	[flat|nested] 10+ messages in thread
* RE: [Announce] Emulex lpfcdriver v8.0.12 available
@ 2004-09-21 17:07 James.Smart
  0 siblings, 0 replies; 10+ messages in thread
From: James.Smart @ 2004-09-21 17:07 UTC (permalink / raw)
  To: hch; +Cc: linux-scsi

The snippet was the result of interacting with our ppc64 partner. Yes - it makes more sense to have the user set this.

-- james

> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@infradead.org]
> Sent: Tuesday, September 21, 2004 12:56 PM
> To: Smart, James
> Cc: linux-scsi@vger.kernel.org
> Subject: Re: [Announce] Emulex lpfcdriver v8.0.12 available
> 
> 
> Hmm, compilation fails for me on ppc64.  The culprit is a 
> little makefile
> fragment which has been in the driver since the beginning:
> 
> ifeq ($(shell uname -m),ppc64)
> ifndef ($(CROSS_COMPILE))
> CROSS_COMPILE := $(shell if [ -e 
> /usr/local/ppc64-current3.0/bin/powerpc64-linux-gcc ]; then \
>     echo /usr/local/ppc64-current3.0/bin/powerpc64-linux-; \
>     else if [ -e /opt/cross/bin/powerpc64-linux-gcc ]; then \
>     echo /opt/cross/bin/powerpc64-linux- ; fi fi)
> endif
> endif
> 
> I don't have a compiler in either of this places, shouldn't 
> it be better
> to rely on the user to always insert the proper CROSS_COMPILE command
> line?  I have for example a ~/bin/make64 script:
> 
> ---- snip ----
> CROSS_COMPILE=powerpc64-unknown-linux-gnu- make ARCH=ppc64 $*
> ---- snip ----
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread
* [Announce] Emulex lpfcdriver v8.0.12 available
@ 2004-09-21  1:34 James.Smart
  2004-09-21 12:40 ` Christoph Hellwig
                   ` (3 more replies)
  0 siblings, 4 replies; 10+ messages in thread
From: James.Smart @ 2004-09-21  1:34 UTC (permalink / raw)
  To: linux-scsi; +Cc: James.Smart

Christoph,

FYI - the 8.0.12 lpfc driver has been posted to SourceForge.

The driver contains the following changes (refer to the ChangeLog for more detail):
- Incorporated the ~9 patches received from you.
- The discovery code was reworked for better organization. Came about as part of supporting the block/unblock patch.
- Started to add management interfaces (used to be ioctls) to sysfs. This is a WIP and quite a few things are expected to ultimately be moved to the fc transport under a separate RFC/patch.

Thanks.

-- James S


The tarball is here:
http://prdownloads.sourceforge.net/lpfcxxxx/lpfcdriver-2.6-8.0.12.tar.gz?download

The full ChangeLog is on SourceForge:
http://sourceforge.net/forum/forum.php?forum_id=408568


^ permalink raw reply	[flat|nested] 10+ messages in thread
end of thread, other threads:[~2004-10-18 21:34 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <0B1E13B586976742A7599D71A6AC733C08664E@xbl3.ma.emulex.com>
2004-10-02 19:36 ` [Announce] Emulex lpfcdriver v8.0.12 available Olaf Hering
2004-10-18 21:34 James.Smart
  -- strict thread matches above, loose matches on Subject: below --
2004-10-16 21:50 James.Smart
2004-10-18 20:55 ` Christoph Hellwig
2004-09-21 17:07 James.Smart
2004-09-21  1:34 James.Smart
2004-09-21 12:40 ` Christoph Hellwig
2004-09-21 12:41 ` Christoph Hellwig
2004-09-21 16:56 ` Christoph Hellwig
2004-10-02 16:38 ` Olaf Hering

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).