All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: James Smart <James.Smart@Emulex.Com>
Cc: Andreas Herrmann <AHERRMAN@de.ibm.com>,
	James Bottomley <jejb@steeleye.com>,
	Linux SCSI <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] fc transport: new attributes for NPIV
Date: Mon, 9 Jan 2006 18:05:13 +0000	[thread overview]
Message-ID: <20060109180513.GA4286@infradead.org> (raw)
In-Reply-To: <43BD574D.8040009@emulex.com>

On Thu, Jan 05, 2006 at 12:28:45PM -0500, James Smart wrote:
> 
> >Problem is that on the mainframe I don't have access to the primary
> >port. Virtualization is done in adapter microcode. I just have
> >access to the virtual port.
> 
> I was afraid you'd say this... that was the other caveat.
> 
> OK - given that the primary port doesn't exist what you have makes
> a lot of sense. I guess we have the 2 options:
> - add the 2 attributes per host
> - create a host and set the attributes  (and this is major overkill)
> 
> I have some reservations about the data passing that allows the virtual
> port to get the physical port data, but it's probably manageable.
> 
> With this direction - your patch is fine, with the caveat that I want
> to explore the most meaningful names for the attributes. Does port_name
> and physical_port_name become odd to a user ? Is some script writer bound
> to assume they always wanted the physical name as they would only see a
> difference if on a mainframe ? What if we change the names to be more
> npiv-centric.  What about ppn (for physical_port_name) and ppn_id (for
> physical_port_id) ?

Actually I think even for Xen-like virtualization it makes most sense that
most domains wouldn't see the Scsi_Host for the phyisical port so this solution
looks most sane to me.  The long name for the physical names sounds fine to me
aswell, much better than un-understandable three-latter acronyms :)


  reply	other threads:[~2006-01-09 18:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <OFE227A343.800436AC-ON412570ED.0055DD4F-412570ED.00560A75@de.ibm.com>
2006-01-05 17:28 ` [PATCH] fc transport: new attributes for NPIV James Smart
2006-01-09 18:05   ` Christoph Hellwig [this message]
2006-01-09 19:04     ` James Smart
2006-01-09 23:09       ` Andreas Herrmann
2006-01-10 18:00         ` James Smart
2006-01-09 23:59     ` Andreas Herrmann
2006-01-10 18:11       ` James Smart
2006-01-05  9:01 Andreas Herrmann
2006-01-05 14:08 ` James Smart
2006-01-05 15:51   ` Andreas Herrmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060109180513.GA4286@infradead.org \
    --to=hch@infradead.org \
    --cc=AHERRMAN@de.ibm.com \
    --cc=James.Smart@Emulex.Com \
    --cc=jejb@steeleye.com \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.