On Tue, 2015-08-18 at 16:53 -0700, Chris Leech wrote: > 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
Yeah and unlikely will ever happen. > (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. > I also think that it is more above end functionality/test cases than having thru w/ HBAAPI. Johannes I should have this confirmed from qual folks at Intel soon, I guess a week or so and then we are good take your -v2 series posted today. Also enough time for anyone to speak for HBAAPI before gone. > > 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. > Agreed, it is OK to trim code and have same functionality w/o old HBAAPI & libhbalinux. Vasu _______________________________________________ fcoe-devel mailing list [email protected] http://lists.open-fcoe.org/mailman/listinfo/fcoe-devel
