On Mon, Aug 17, 2015 at 09:38:38PM +0200, Hannes Reinecke wrote: > 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).
While it would be nice to have one top level library supported by the OSVs, it never really played out that way (although I'm honestly not sure who's shipping what in this space, I assume there are more vendor specific versions around than anyone would like). And libhbalinux never fully developed into a complete implementation over the native OS interfaces capable of replacing the plug-in provider model and vendor specific libraries. The libs may still have their uses (Vasu mentioned that it was at some point an EMC cert requirement), but it may be that fcoeadm was providing a test case for them more than benefiting much from their use. > 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. I agree that it doesn't make sense to cling to the HBAAPI if there's not a need to be portable. fcoemon is used for a subset of FCoE solutions on Linux, and I don't see fcoeadm being the go to tool for FC diagnostics beyond those. If fcoeadm can be improved by dropping the use of HBAAPI, I'm OK with it. - Chris _______________________________________________ fcoe-devel mailing list fcoe-devel@open-fcoe.org http://lists.open-fcoe.org/mailman/listinfo/fcoe-devel
