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
