[Open-FCoE] [PATCH 1/3] libhbalinux: Replace libHBAAPI with direct call to T11 FC-HBA APIs

Ma, Steve steve.ma at intel.com
Wed Apr 22 01:27:07 UTC 2009



>-----Original Message-----
>From: Love, Robert W
>Sent: Tuesday, April 21, 2009 5:36 PM
>To: Ma, Steve
>Cc: Leech, Christopher; devel at open-fcoe.org
>Subject: Re: [Open-FCoE] [PATCH 1/3] libhbalinux: Replace libHBAAPI with
>direct call to T11 FC-HBA APIs
>
>On Thu, 2009-03-05 at 17:29 -0800, Ma, Steve wrote:
>>
>> >-----Original Message-----
>> >From: Leech, Christopher
>> >Sent: Thursday, March 05, 2009 5:14 PM
>> >To: Ma, Steve
>> >Cc: devel at open-fcoe.org
>> >Subject: Re: [Open-FCoE] [PATCH 1/3] libhbalinux: Replace libHBAAPI with
>> >direct call to T11 FC-HBA APIs
>> >
>> >On Thu, 2009-03-05 at 15:28 -0800, Steve Ma wrote:
>> >> Add direct calls from FC-HBA APIs to libhbalinux routines and
>> >> remove the dependency of SNIA libHBAAPI library.
>> >>
>> >> A new include file hbaapi.h is created from Fibre Channel HBA API
>> >> (FC-HBA) Rev 14. 4 February 2004 (04-137v0). This must be included
>> >> in any C code using the libhbalinux library.
>> >>
>> >> Signed-off-by: Steve Ma <steve.ma at intel.com>
>> >
>> >> diff --git a/hbaapi.h b/hbaapi.h
>> >> new file mode 100644
>> >> index 0000000..9134d35
>> >> --- /dev/null
>> >> +++ b/hbaapi.h
>> >> @@ -0,0 +1,874 @@
>> >> +/*
>> >> + * Copyright (c) 2008, Intel Corporation.
>> >> + *
>> >
>> >It's 2009.  New code, and especially new files, should reflect that.
>> >
>> >> diff --git a/lib.c b/lib.c
>> >> index 623b126..42d9fa3 100644
>> >> --- a/lib.c
>> >> +++ b/lib.c
>> >
>> >> +/* 7.3 HBA and Port Information Functions */
>> >> +
>> >> +/* 7.3.1 */
>> >> +HBA_STATUS HBA_GetAdapterName(
>> >> +       HBA_UINT32 adapterindex,
>> >> +       char *pAdaptername)
>> >> +{
>> >> +       return adapter_get_name(adapterindex, pAdaptername);
>> >> +}
>> >
>> >There's a giant list of these wrapper functions.
>> >
>> >I think we should either just change the internal function names to the
>> >official API names, or after each internal function define a symbol
>> >alias.
>> >
>> >Obviously that doesn't apply to all the new functions that just return
>> >NOT_SUPPORTED.
>> >
>> >- Chris
>> >
>> I am trying to put all the API entry points in the same place to make it
>easier to find the supported and unsupported ones. -Steve
>
>Has this been resolved? I don't see a repost and at least the copyright
>needed to be changed. It looks like Chris was looking for something
>different regarding the naming too.
>
Since Chris take over the build environment, I have not continued the work.




More information about the devel mailing list