linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: James Smart <james.smart@broadcom.com>
Cc: Roland Dreier <roland@purestorage.com>,
	Sebastian Herbszt <herbszt@gmx.de>,
	"Nicholas A. Bellinger" <nab@linux-iscsi.org>,
	jsmart2021@gmail.com,
	Linux SCSI Mailinglist <linux-scsi@vger.kernel.org>,
	target-devel <target-devel@vger.kernel.org>
Subject: Re: [ANNOUNCE]: Broadcom (Emulex) FC Target driver - efct
Date: Tue, 13 Jun 2017 11:34:42 -0400	[thread overview]
Message-ID: <yq137b3yk8d.fsf@oracle.com> (raw)
In-Reply-To: <55205e7e-e1c6-5f09-8dd3-338492728dfe@broadcom.com> (James Smart's message of "Mon, 12 Jun 2017 16:08:24 -0700")


James,

> To start this effort, I'd like a bcmlpfc directory to be made within
> the drivers staging tree. The directory would be populated with the
> efct driver and a copy of the existing lpfc driver.  Work can then
> commence on refactoring lpfc and creating the libraries and
> integrating the libraries into both drivers.  As lpfc is updated in
> the main tree, patches would be posted to the staging version of lpfc
> to keep them on par.

Sounds good to me.

> a) How best to deal with overlapping pci id's ?  E.g. if we do (1) and
> we have an initiator and target driver, there is a lot of adapters
> that are fully functional for target operation, but were sold as
> primarily an initiator adapter. How could we manage target mode
> enablement without code mod or hard pci id partitioning ?  I know
> individual pci unbind/bind could work, but its been frowned upon as a
> long term option. Same thing goes for module parameters to select
> which ports do what role.

I don't have a problem with the binding approach. A bit easier for the
sysadmin to script and manage compared to PCI ID-specific module
parameters that may come with initramfs rebuilds or grub tweaks and
reboots.

I also think the binding approach eases that pain for systems that want,
say, initiator for root fs on one port and target on the other. And
gives you the flexibility to use the WWN or sysfs attributes other than
the PCI ID to locate the ports whose affiliation you want to change.

> b) Assuming we have the lpfc copy in the bcmlpfc directory in the
> staging tree: are there any issues with having a version of lpfc in the
> main tree and another in the staging tree ?     For many reasons, I'd
> like to keep the name lpfc on the initiator driver in the staging
> tree. But is that possible ? I assume we would need to develop in the
> staging tree as a new name and pci id space separate from the base
> driver, and we can rename the staging driver to the lpfc name when it
> merges into the main kernel and replaces the existing driver.

I'm with Christoph in terms of avoiding staging. It's better to do out
of tree. And as far as naming is concerned, you have some flexibility in
terms of string prefixes for printk's, module aliases, etc. And then a
final tweak to get things shuffled into place before merging into
mainline.

-- 
Martin K. Petersen	Oracle Linux Engineering

  parent reply	other threads:[~2017-06-13 15:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-27 23:28 [ANNOUNCE]: Broadcom (Emulex) FC Target driver - efct James Smart
2017-02-28 16:34 ` Hannes Reinecke
2017-02-28 18:14   ` James Smart
2017-03-01  9:40     ` Hannes Reinecke
2017-03-02 20:08 ` Nicholas A. Bellinger
2017-03-05 16:35   ` Sebastian Herbszt
2017-03-06 17:53     ` Bart Van Assche
2017-05-16 19:59     ` Roland Dreier
2017-06-12 23:08       ` James Smart
2017-06-13  6:31         ` Christoph Hellwig
2017-06-13  8:29         ` Johannes Thumshirn
2017-06-13 15:34         ` Martin K. Petersen [this message]
2017-06-14 11:40         ` Hannes Reinecke
2017-06-14 20:02           ` Sebastian Herbszt
2017-06-16  6:38             ` Hannes Reinecke
2017-03-17  0:10 ` Bart Van Assche

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=yq137b3yk8d.fsf@oracle.com \
    --to=martin.petersen@oracle.com \
    --cc=herbszt@gmx.de \
    --cc=james.smart@broadcom.com \
    --cc=jsmart2021@gmail.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=nab@linux-iscsi.org \
    --cc=roland@purestorage.com \
    --cc=target-devel@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 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).