On 08/17/2015 08:48 PM, Vasu Dev wrote: > On Wed, 2015-08-12 at 13:46 +0200, Johannes Thumshirn wrote: >> This patch series replaces all usage of libHBAAPIv2 and libhbalinux2 from >> fcoe-utils and replaces them with an internal version operating directly on >> the >> respective sysfs files. >> >> This removes the two dependencies but pulls in libpciacces (which got pulled >> in >> by libhbalinux2 in the current version of fcoe-utils). Nevertheless this way >> it >> is possible to get rid of a lot of code. >> > > Yes this is big plus as you said it removes two packages dependency > completely libHBAAPI and libhbalinux, significant code removal. > > However the *old* libHBAAPI is common library across multiple HBA > vendors and potentially can be leveraged by all FC/FCoE vendors to > manage their FC/FCoE HBA by simply supplying their HBA specific vendor > library as libhbalinux for fcoe HBAs. Idea was to use common user tools > for all FC/FCoE HBAs but that is still not the case so far, nevertheless > libHBAAPI might be still in use by other FC vendors tools since we had > some co-existence issues in past with other FC tools install. Also, > possibly used in EMC certs tools also. So Johannes are you set to remove > libHBAAPI completely ? If so then did you check any other users of > libHBAAPI, which could be on released Linux distors also ? > > Chris Leech from Red Hat is still active on fcoe and he was among > original significant contributor to these packages, so adding him for > his feedback on removing libHBAAPI. Also adding Hannes from SuSe for > same reasons. They might have more to this discussion. > Actually Johannes did this patch based on my recommendation :-)
The big problem we have with HBAAPI is that it's a standard which doesn't align properly with linux or packaging. HBAAPI itself is an abstract library, which is supposed to provide an independent means of accessing HBA information. It then requires an additional, vendor specific library (libhbalinux in our case) which the 'feeds' information into HBAAPI. As per design HBAAPI is _independent_, and as such it can be provided by any vendor. So libhbalinux cannot be dependent on HBAAPI, as the HBAAPI library can (in theory) be provided by other vendors. (IIRC Emulex does this). So we always have to carry hacks in our installation services to ensure HBAAPI is installed, and cannot rely on 'normal' rpm dependencies here. And this patch shows, the very same information HBAAPI attempts to provide can be gathered via sysfs, so that functionality-wise this is not required. Plus fcoeadm is specific to linux FCoE, so a HBAAPI implementation from other vendors will have a very limited useability. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage [email protected] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) _______________________________________________ fcoe-devel mailing list [email protected] http://lists.open-fcoe.org/mailman/listinfo/fcoe-devel
