[PATCH] opensm: event plig-in API fixed to compile with g++

[PATCH] opensm: event plig-in API fixed to compile with g++

[Yevgeny Kliteynik]

Event API should have been able to be used by libraries
written both in C and C++. The problem is, one of the
fields in struct osm_event_plugin is called "delete".
Changing it to "destroy" and promoting the API version.

Signed-off-by: Yevgeny Kliteynik <kliteyn-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
---
 opensm/include/opensm/osm_event_plugin.h    |    2 +-
 opensm/opensm/osm_event_plugin.c            |    4 ++--
 opensm/osmeventplugin/libosmeventplugin.ver |    2 +-
 opensm/osmeventplugin/src/osmeventplugin.c  |    2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/opensm/include/opensm/osm_event_plugin.h b/opensm/include/opensm/osm_event_plugin.h
index 0b3464e..aa3fed4 100644
--- a/opensm/include/opensm/osm_event_plugin.h
+++ b/opensm/include/opensm/osm_event_plugin.h
@@ -145,7 +145,7 @@ typedef struct osm_api_ps_event {
 typedef struct osm_event_plugin {
 	const char *osm_version;
 	void *(*create) (struct osm_opensm *osm);
-	void (*delete) (void *plugin_data);
+	void (*destroy) (void *plugin_data);
 	void (*report) (void *plugin_data, osm_epi_event_id_t event_id,
 			void *event_data);
 } osm_event_plugin_t;
diff --git a/opensm/opensm/osm_event_plugin.c b/opensm/opensm/osm_event_plugin.c
index 2d67065..7f61960 100644
--- a/opensm/opensm/osm_event_plugin.c
+++ b/opensm/opensm/osm_event_plugin.c
@@ -141,8 +141,8 @@ DLOPENFAIL:
 void osm_epi_destroy(osm_epi_plugin_t * plugin)
 {
 	if (plugin) {
-		if (plugin->impl->delete)
-			plugin->impl->delete(plugin->plugin_data);
+		if (plugin->impl->destroy)
+			plugin->impl->destroy(plugin->plugin_data);
 		dlclose(plugin->handle);
 		free(plugin->plugin_name);
 		free(plugin);
diff --git a/opensm/osmeventplugin/libosmeventplugin.ver b/opensm/osmeventplugin/libosmeventplugin.ver
index f755ff6..0c3a85b 100644
--- a/opensm/osmeventplugin/libosmeventplugin.ver
+++ b/opensm/osmeventplugin/libosmeventplugin.ver
@@ -6,4 +6,4 @@
 # API_REV - advance on any added API
 # RUNNING_REV - advance any change to the vendor files
 # AGE - number of backward versions the API still supports
-LIBVERSION=1:0:0
+LIBVERSION=2:0:0
diff --git a/opensm/osmeventplugin/src/osmeventplugin.c b/opensm/osmeventplugin/src/osmeventplugin.c
index f40f7fe..a82be07 100644
--- a/opensm/osmeventplugin/src/osmeventplugin.c
+++ b/opensm/osmeventplugin/src/osmeventplugin.c
@@ -207,6 +207,6 @@ static void report(void *_log, osm_epi_event_id_t event_id, void *event_data)
 osm_event_plugin_t osm_event_plugin = {
       osm_version:OSM_VERSION,
       create:construct,
-      delete:destroy,
+      destroy:destroy,
       report:report
 };
-- 
1.5.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RDMA synchronous operations

[Andrea Gozzelino]

Hi all,

I’m testing the latency time of an RDMA system (2 card and 1 switch).
The connection server/client is established and the code is just as
mirror on both sides.

The RDMA action scheme is below:
1-	client sends a buffer;
2-	server receives a buffer;
3-	server sends a buffer;
4-	client receives a buffer.

The scheme is in a for loop, so after step 4 client repeats step 1.
On client side I put a clock: t_start is before loop and t_end is after
loop.
I consider the round trip time RTT as (t_end-t_start)/NTX where NTX is
number of transfer (number of loop). The latency time is half RTT, if
transfer time is negligible, i.e. for small (8 Bytes – 4 Kbytes) buffer
size and high NTX value (> 10000) is true.

The RDMA communication stops casually with error status 5. It means that
the send or receive operation on one side (server or client) casually is
not in time. I summarize post_send and post_receive operation are
quasi-synchronous. I would like that RDMA operation are completely
synchronous. I use the completion queue and the acknowledgement event.

Do you see the same character in other RDMA use? How can I synchronize
all RDMA operation?
Could you please give me some suggestions?

Thank you very much,
Andrea

Example of structure code:
Ibv_recv_wr rrq(mr), *bad_rrq;
		assert(!conn->post_recv(&rrq, &bad_rrq, 0));
		assert(!conn->get_completion(&compl_queue));
		//printf("ok %p %s\n", compl_queue, strerror(errno));
		assert(1 == compl_queue->poll(1, &wc));
		//printf("status %i\n", (int)wc.status);
		if (wc.status !=0){
			printf("RDMA server closes. \n");
			break;
------
Ibv_send_wr srq((void *)rpd->address, rpd->rkey), *bad_srq;
  		srq.add_sge(mr);
  		assert(!conn.post_send(&srq, &bad_srq, 0));
  		assert(!conn.get_completion(&compl_queue));
  		assert(1 == compl_queue->poll(1, &wc));
  
		//printf("ok %p %s status %i\n", compl_queue, strerror(errno),
  wc.status);
  		//printf("loop %i\n", i);
  
  		if (wc.status != 0){
			//printf("KO %p %s status %i\n", compl_queue, strerror(errno),
  wc.status);
  			printf("RDMA data sending problem in loop %i.\n", i);
  			break;
  		}
-----
Andrea Gozzelino

INFN - Laboratori Nazionali di Legnaro	(LNL)
Viale dell'Universita' 2 -I-35020 - Legnaro (PD)- ITALIA
Office: E-101
Tel: +39 049 8068346
Fax: +39 049 641925
Mail: andrea.gozzelino-PK20h7lG/Rc1GQ1Ptb7lUw@public.gmane.org
Cell: +39 3488245552				

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RDMA synchronous operations

[Dotan Barak]

Hi.

On 24/06/2010 16:36, Andrea Gozzelino wrote:
> Hi all,
>
> I’m testing the latency time of an RDMA system (2 card and 1 switch).
> The connection server/client is established and the code is just as
> mirror on both sides.
>
> The RDMA action scheme is below:
> 1-	client sends a buffer;
> 2-	server receives a buffer;
> 3-	server sends a buffer;
> 4-	client receives a buffer.
>
> The scheme is in a for loop, so after step 4 client repeats step 1.
> On client side I put a clock: t_start is before loop and t_end is after
> loop.
> I consider the round trip time RTT as (t_end-t_start)/NTX where NTX is
> number of transfer (number of loop). The latency time is half RTT, if
> transfer time is negligible, i.e. for small (8 Bytes – 4 Kbytes) buffer
> size and high NTX value (>  10000) is true.
>
> The RDMA communication stops casually with error status 5. It means that
> the send or receive operation on one side (server or client) casually is
> not in time. I summarize post_send and post_receive operation are
> quasi-synchronous. I would like that RDMA operation are completely
> synchronous. I use the completion queue and the acknowledgement event.
>
>    
Do you have any asynchronous event handler on the QP/SRQ?
(maybe there is an error on your QP/SRQ)

Did you get any completion with error before the completion with status 5?

Dotan
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] opensm: event plig-in API fixed to compile with g++

[Sasha Khapyorsky]

On 11:10 Thu 24 Jun     , Yevgeny Kliteynik wrote:
> Event API should have been able to be used by libraries
> written both in C and C++.

I don't know about such requirement. Personally I would strongly suggest
to not mix things without really good reason - we discussed already about
"extern "C"" removal in a future.

> The problem is, one of the
> fields in struct osm_event_plugin is called "delete".
> Changing it to "destroy" and promoting the API version.

This will break any existing plugin now (I know at least couple). I
don't think that such change is appropriate for "between RCs" period.

Sasha

> Signed-off-by: Yevgeny Kliteynik <kliteyn-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
> ---
>  opensm/include/opensm/osm_event_plugin.h    |    2 +-
>  opensm/opensm/osm_event_plugin.c            |    4 ++--
>  opensm/osmeventplugin/libosmeventplugin.ver |    2 +-
>  opensm/osmeventplugin/src/osmeventplugin.c  |    2 +-
>  4 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/opensm/include/opensm/osm_event_plugin.h b/opensm/include/opensm/osm_event_plugin.h
> index 0b3464e..aa3fed4 100644
> --- a/opensm/include/opensm/osm_event_plugin.h
> +++ b/opensm/include/opensm/osm_event_plugin.h
> @@ -145,7 +145,7 @@ typedef struct osm_api_ps_event {
>  typedef struct osm_event_plugin {
>  	const char *osm_version;
>  	void *(*create) (struct osm_opensm *osm);
> -	void (*delete) (void *plugin_data);
> +	void (*destroy) (void *plugin_data);
>  	void (*report) (void *plugin_data, osm_epi_event_id_t event_id,
>  			void *event_data);
>  } osm_event_plugin_t;
> diff --git a/opensm/opensm/osm_event_plugin.c b/opensm/opensm/osm_event_plugin.c
> index 2d67065..7f61960 100644
> --- a/opensm/opensm/osm_event_plugin.c
> +++ b/opensm/opensm/osm_event_plugin.c
> @@ -141,8 +141,8 @@ DLOPENFAIL:
>  void osm_epi_destroy(osm_epi_plugin_t * plugin)
>  {
>  	if (plugin) {
> -		if (plugin->impl->delete)
> -			plugin->impl->delete(plugin->plugin_data);
> +		if (plugin->impl->destroy)
> +			plugin->impl->destroy(plugin->plugin_data);
>  		dlclose(plugin->handle);
>  		free(plugin->plugin_name);
>  		free(plugin);
> diff --git a/opensm/osmeventplugin/libosmeventplugin.ver b/opensm/osmeventplugin/libosmeventplugin.ver
> index f755ff6..0c3a85b 100644
> --- a/opensm/osmeventplugin/libosmeventplugin.ver
> +++ b/opensm/osmeventplugin/libosmeventplugin.ver
> @@ -6,4 +6,4 @@
>  # API_REV - advance on any added API
>  # RUNNING_REV - advance any change to the vendor files
>  # AGE - number of backward versions the API still supports
> -LIBVERSION=1:0:0
> +LIBVERSION=2:0:0
> diff --git a/opensm/osmeventplugin/src/osmeventplugin.c b/opensm/osmeventplugin/src/osmeventplugin.c
> index f40f7fe..a82be07 100644
> --- a/opensm/osmeventplugin/src/osmeventplugin.c
> +++ b/opensm/osmeventplugin/src/osmeventplugin.c
> @@ -207,6 +207,6 @@ static void report(void *_log, osm_epi_event_id_t event_id, void *event_data)
>  osm_event_plugin_t osm_event_plugin = {
>        osm_version:OSM_VERSION,
>        create:construct,
> -      delete:destroy,
> +      destroy:destroy,
>        report:report
>  };
> -- 
> 1.5.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] opensm: event plig-in API fixed to compile with g++

[Hal Rosenstock]

On Mon, Jul 5, 2010 at 2:11 PM, Sasha Khapyorsky <sashak-smomgflXvOZWk0Htik3J/w@public.gmane.org> wrote:
> On 11:10 Thu 24 Jun     , Yevgeny Kliteynik wrote:
>> Event API should have been able to be used by libraries
>> written both in C and C++.
>
> I don't know about such requirement.

Are you saying it isn't a valid requirement to allow OpenSM plugins to
be C++ based ? If so, why not ?

-- Hal
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] opensm: event plig-in API fixed to compile with g++

[Sasha Khapyorsky]

On 14:30 Mon 05 Jul     , Hal Rosenstock wrote:
> On Mon, Jul 5, 2010 at 2:11 PM, Sasha Khapyorsky <sashak-smomgflXvOZWk0Htik3J/w@public.gmane.org> wrote:
> > On 11:10 Thu 24 Jun     , Yevgeny Kliteynik wrote:
> >> Event API should have been able to be used by libraries
> >> written both in C and C++.
> >
> > I don't know about such requirement.
> 
> Are you saying it isn't a valid requirement to allow OpenSM plugins to
> be C++ based ? If so, why not ?

I'm saying that there is no requirement for plugin API to support C++ -
obviously (following method names) plugin API was never developed for
using it in C++.

Why not is another question - for instance in order to not deal with
C/C++ compatibility issues (such as castings, function names limitation,
linking mess, etc.)

Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] opensm: event plig-in API fixed to compile with g++

[Hal Rosenstock]

On Mon, Jul 5, 2010 at 2:41 PM, Sasha Khapyorsky <sashak-smomgflXvOZWk0Htik3J/w@public.gmane.org> wrote:
> On 14:30 Mon 05 Jul     , Hal Rosenstock wrote:
>> On Mon, Jul 5, 2010 at 2:11 PM, Sasha Khapyorsky <sashak-smomgflXvObQFizaE/u3fw@public.gmane.orgm> wrote:
>> > On 11:10 Thu 24 Jun     , Yevgeny Kliteynik wrote:
>> >> Event API should have been able to be used by libraries
>> >> written both in C and C++.
>> >
>> > I don't know about such requirement.
>>
>> Are you saying it isn't a valid requirement to allow OpenSM plugins to
>> be C++ based ? If so, why not ?
>
> I'm saying that there is no requirement for plugin API to support C++ -
> obviously (following method names) plugin API was never developed for
> using it in C++.
>
> Why not is another question - for instance in order to not deal with
> C/C++ compatibility issues (such as castings, function names limitation,
> linking mess, etc.)

Seems to me like being able to build plugins in C++ would be very
useful and that the remaining issues to accomplish it seem relatively
minor. Are you opposed to moving in this direction ?

-- Hal

>
> Sasha
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] opensm: event plig-in API fixed to compile with g++

[Sasha Khapyorsky]

On 14:49 Mon 05 Jul     , Hal Rosenstock wrote:
> 
> Seems to me like being able to build plugins in C++ would be very
> useful

For what it should be useful? Any example?

> and that the remaining issues to accomplish it seem relatively
> minor. Are you opposed to moving in this direction ?

OpenSM is written in C, not C++, I'm pretty fine with it and don't see
any reason to get C++ direction.

Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] opensm: event plig-in API fixed to compile with g++

[Hal Rosenstock]

On Mon, Jul 5, 2010 at 6:52 PM, Sasha Khapyorsky <sashak-smomgflXvOZWk0Htik3J/w@public.gmane.org> wrote:
> On 14:49 Mon 05 Jul     , Hal Rosenstock wrote:
>>
>> Seems to me like being able to build plugins in C++ would be very
>> useful
>
> For what it should be useful? Any example?

Any management plug in application.

>> and that the remaining issues to accomplish it seem relatively
>> minor. Are you opposed to moving in this direction ?
>
> OpenSM is written in C, not C++, I'm pretty fine with it and don't see
> any reason to get C++ direction.

That's OpenSM but why limit plug in writers to C ?

-- Hal

> Sasha
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] opensm: event plig-in API fixed to compile with g++

[Hefty, Sean]

> > OpenSM is written in C, not C++, I'm pretty fine with it and don't see
> > any reason to get C++ direction.
> 
> That's OpenSM but why limit plug in writers to C ?

FWIW, I agree with Hal.  Support for external plug-ins written in C++ seems desirable.

Re: [PATCH] opensm: event plig-in API fixed to compile with g++

[Roland Dreier]

 > FWIW, I agree with Hal.  Support for external plug-ins written in C++ seems desirable.

Seems that anyone who cared could already easily write a tiny shim in C
and then write the rest of their plugin in C++.  Or are there deeper
issues than names of methods?

 - R.
-- 
Roland Dreier <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] opensm: event plig-in API fixed to compile with g++

[Sasha Khapyorsky]

On 10:00 Tue 06 Jul     , Roland Dreier wrote:
> 
> Seems that anyone who cared could already easily write a tiny shim in C
> and then write the rest of their plugin in C++.  Or are there deeper
> issues than names of methods?

I think that it is likely deeper. For instance if C++ stuff will use
OpenSM structures, functions, include files, etc.. So this will
automatically will add some limitations for using normal C in OpenSM
core code.

I highly suspect that all those "requirements" are resulted by using C++
in some third party's *proprietary* plugs. Which is fine in general, but
completely unrelated to OpenSM development - I don't think that we should
care.

Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] opensm: event plig-in API fixed to compile with g++

[Hal Rosenstock]

On Wed, Jul 7, 2010 at 9:58 AM, Sasha Khapyorsky <sashak-smomgflXvOZWk0Htik3J/w@public.gmane.org> wrote:
> On 10:00 Tue 06 Jul     , Roland Dreier wrote:
>>
>> Seems that anyone who cared could already easily write a tiny shim in C
>> and then write the rest of their plugin in C++.  Or are there deeper
>> issues than names of methods?
>
> I think that it is likely deeper. For instance if C++ stuff will use
> OpenSM structures, functions, include files, etc.. So this will
> automatically will add some limitations for using normal C in OpenSM
> core code.

Perhaps but are these significant ? AFAIK we been living with them
since the early days of OpenSM.

> I highly suspect that all those "requirements" are resulted by using C++
> in some third party's *proprietary* plugs.

It's not just "some third party's "proprietary" plugs."

C++ use has been in open source in OpenFabrics for quite some time now
in ibutils.

Also, since "extern C" has been in the header files since the early
days, there can be many out of tree uses in C++ code.

> Which is fine in general, but
> completely unrelated to OpenSM development - I don't think that we should
> care.

IMHO if users want to use C++ with OpenSM related development then we
should and need to care.

-- Hal

> Sasha
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] opensm: event plig-in API fixed to compile with g++

[Ira Weiny]

On Mon, 5 Jul 2010 11:41:44 -0700
Sasha Khapyorsky <sashak-smomgflXvOZWk0Htik3J/w@public.gmane.org> wrote:

> On 14:30 Mon 05 Jul     , Hal Rosenstock wrote:
> > On Mon, Jul 5, 2010 at 2:11 PM, Sasha Khapyorsky <sashak@voltaire.com> wrote:
> > > On 11:10 Thu 24 Jun     , Yevgeny Kliteynik wrote:
> > >> Event API should have been able to be used by libraries
> > >> written both in C and C++.
> > >
> > > I don't know about such requirement.
> > 
> > Are you saying it isn't a valid requirement to allow OpenSM plugins to
> > be C++ based ? If so, why not ?
> 
> I'm saying that there is no requirement for plugin API to support C++ -
> obviously (following method names) plugin API was never developed for
> using it in C++.

Actually IMO this is not correct.  The use of "delete" was introduced by commit a5963f93fa3d4514cc526e4ad029b036724b8167.  I was at fault to not have objected back then.  The use of "extern C" in all of the header files below implies a desire to support C++.

10:28:14 > pwd; grep "BEGIN_C_DECLS extern" *
/home/weiny2/OpenIB/git-trees/management/opensm/include/opensm
osm_attrib_req.h:#  define BEGIN_C_DECLS extern "C" {
osm_base.h:#  define BEGIN_C_DECLS extern "C" {
osm_console.h:#  define BEGIN_C_DECLS extern "C" {
osm_console_io.h:#  define BEGIN_C_DECLS extern "C" {
osm_db.h:#  define BEGIN_C_DECLS extern "C" {
osm_db_pack.h:#  define BEGIN_C_DECLS extern "C" {
osm_event_plugin.h:#  define BEGIN_C_DECLS extern "C" {
osm_helper.h:#  define BEGIN_C_DECLS extern "C" {
osm_inform.h:#  define BEGIN_C_DECLS extern "C" {
osm_lid_mgr.h:#  define BEGIN_C_DECLS extern "C" {
osm_log.h:#  define BEGIN_C_DECLS extern "C" {
osm_mad_pool.h:#  define BEGIN_C_DECLS extern "C" {
osm_madw.h:#  define BEGIN_C_DECLS extern "C" {
osm_mcast_tbl.h:#  define BEGIN_C_DECLS extern "C" {
osm_mcm_port.h:#  define BEGIN_C_DECLS extern "C" {
osm_msgdef.h:#  define BEGIN_C_DECLS extern "C" {
osm_mtree.h:#  define BEGIN_C_DECLS extern "C" {
osm_multicast.h:#  define BEGIN_C_DECLS extern "C" {
osm_node.h:#  define BEGIN_C_DECLS extern "C" {
osm_opensm.h:#  define BEGIN_C_DECLS extern "C" {
osm_partition.h:#  define BEGIN_C_DECLS extern "C" {
osm_path.h:#  define BEGIN_C_DECLS extern "C" {
osm_perfmgr_db.h:#  define BEGIN_C_DECLS extern "C" {
osm_pkey.h:#  define BEGIN_C_DECLS extern "C" {
osm_port.h:#  define BEGIN_C_DECLS extern "C" {
osm_port_profile.h:#  define BEGIN_C_DECLS extern "C" {
osm_prefix_route.h:#  define BEGIN_C_DECLS extern "C" {
osm_remote_sm.h:#  define BEGIN_C_DECLS extern "C" {
osm_router.h:#  define BEGIN_C_DECLS extern "C" {
osm_sa.h:#  define BEGIN_C_DECLS extern "C" {
osm_sa_mad_ctrl.h:#  define BEGIN_C_DECLS extern "C" {
osm_service.h:#  define BEGIN_C_DECLS extern "C" {
osm_sm.h:#  define BEGIN_C_DECLS extern "C" {
osm_sm.h.orig:#  define BEGIN_C_DECLS extern "C" {
osm_sm_mad_ctrl.h:#  define BEGIN_C_DECLS extern "C" {
osm_stats.h:#  define BEGIN_C_DECLS extern "C" {
osm_subnet.h:#  define BEGIN_C_DECLS extern "C" {
osm_subnet.h.orig:#  define BEGIN_C_DECLS extern "C" {
osm_switch.h:#  define BEGIN_C_DECLS extern "C" {
osm_ucast_cache.h:#  define BEGIN_C_DECLS extern "C" {
osm_ucast_mgr.h:#  define BEGIN_C_DECLS extern "C" {
osm_vl15intf.h:#  define BEGIN_C_DECLS extern "C" {
st.h:#  define BEGIN_C_DECLS extern "C" {

Ira

> 
> Why not is another question - for instance in order to not deal with
> C/C++ compatibility issues (such as castings, function names limitation,
> linking mess, etc.)
> 
> Sasha
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://*vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] opensm: event plig-in API fixed to compile with g++

[Yevgeny Kliteynik]

On 07-Jul-10 12:03 AM, Ira Weiny wrote:
> On Mon, 5 Jul 2010 11:41:44 -0700
> Sasha Khapyorsky<sashak-smomgflXvOZWk0Htik3J/w@public.gmane.org>  wrote:
>
>> On 14:30 Mon 05 Jul     , Hal Rosenstock wrote:
>>> On Mon, Jul 5, 2010 at 2:11 PM, Sasha Khapyorsky<sashak-smomgflXvOZWk0Htik3J/w@public.gmane.org>  wrote:
>>>> On 11:10 Thu 24 Jun     , Yevgeny Kliteynik wrote:
>>>>> Event API should have been able to be used by libraries
>>>>> written both in C and C++.
>>>>
>>>> I don't know about such requirement.
>>>
>>> Are you saying it isn't a valid requirement to allow OpenSM plugins to
>>> be C++ based ? If so, why not ?
>>
>> I'm saying that there is no requirement for plugin API to support C++ -
>> obviously (following method names) plugin API was never developed for
>> using it in C++.
>
> Actually IMO this is not correct.  The use of "delete" was introduced
> by commit a5963f93fa3d4514cc526e4ad029b036724b8167.  I was at fault to
> not have objected back then.  The use of "extern C" in all of the header
> files below implies a desire to support C++.

Couldn't agree more.

-- Yevgeny

> 10:28:14>  pwd; grep "BEGIN_C_DECLS extern" *
> /home/weiny2/OpenIB/git-trees/management/opensm/include/opensm
> osm_attrib_req.h:#  define BEGIN_C_DECLS extern "C" {
> osm_base.h:#  define BEGIN_C_DECLS extern "C" {
> osm_console.h:#  define BEGIN_C_DECLS extern "C" {
> osm_console_io.h:#  define BEGIN_C_DECLS extern "C" {
> osm_db.h:#  define BEGIN_C_DECLS extern "C" {
> osm_db_pack.h:#  define BEGIN_C_DECLS extern "C" {
> osm_event_plugin.h:#  define BEGIN_C_DECLS extern "C" {
> osm_helper.h:#  define BEGIN_C_DECLS extern "C" {
> osm_inform.h:#  define BEGIN_C_DECLS extern "C" {
> osm_lid_mgr.h:#  define BEGIN_C_DECLS extern "C" {
> osm_log.h:#  define BEGIN_C_DECLS extern "C" {
> osm_mad_pool.h:#  define BEGIN_C_DECLS extern "C" {
> osm_madw.h:#  define BEGIN_C_DECLS extern "C" {
> osm_mcast_tbl.h:#  define BEGIN_C_DECLS extern "C" {
> osm_mcm_port.h:#  define BEGIN_C_DECLS extern "C" {
> osm_msgdef.h:#  define BEGIN_C_DECLS extern "C" {
> osm_mtree.h:#  define BEGIN_C_DECLS extern "C" {
> osm_multicast.h:#  define BEGIN_C_DECLS extern "C" {
> osm_node.h:#  define BEGIN_C_DECLS extern "C" {
> osm_opensm.h:#  define BEGIN_C_DECLS extern "C" {
> osm_partition.h:#  define BEGIN_C_DECLS extern "C" {
> osm_path.h:#  define BEGIN_C_DECLS extern "C" {
> osm_perfmgr_db.h:#  define BEGIN_C_DECLS extern "C" {
> osm_pkey.h:#  define BEGIN_C_DECLS extern "C" {
> osm_port.h:#  define BEGIN_C_DECLS extern "C" {
> osm_port_profile.h:#  define BEGIN_C_DECLS extern "C" {
> osm_prefix_route.h:#  define BEGIN_C_DECLS extern "C" {
> osm_remote_sm.h:#  define BEGIN_C_DECLS extern "C" {
> osm_router.h:#  define BEGIN_C_DECLS extern "C" {
> osm_sa.h:#  define BEGIN_C_DECLS extern "C" {
> osm_sa_mad_ctrl.h:#  define BEGIN_C_DECLS extern "C" {
> osm_service.h:#  define BEGIN_C_DECLS extern "C" {
> osm_sm.h:#  define BEGIN_C_DECLS extern "C" {
> osm_sm.h.orig:#  define BEGIN_C_DECLS extern "C" {
> osm_sm_mad_ctrl.h:#  define BEGIN_C_DECLS extern "C" {
> osm_stats.h:#  define BEGIN_C_DECLS extern "C" {
> osm_subnet.h:#  define BEGIN_C_DECLS extern "C" {
> osm_subnet.h.orig:#  define BEGIN_C_DECLS extern "C" {
> osm_switch.h:#  define BEGIN_C_DECLS extern "C" {
> osm_ucast_cache.h:#  define BEGIN_C_DECLS extern "C" {
> osm_ucast_mgr.h:#  define BEGIN_C_DECLS extern "C" {
> osm_vl15intf.h:#  define BEGIN_C_DECLS extern "C" {
> st.h:#  define BEGIN_C_DECLS extern "C" {
>
> Ira
>
>>
>> Why not is another question - for instance in order to not deal with
>> C/C++ compatibility issues (such as castings, function names limitation,
>> linking mess, etc.)
>>
>> Sasha
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at  http://*vger.kernel.org/majordomo-info.html
>>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] opensm: event plig-in API fixed to compile with g++

[Yevgeny Kliteynik]

On 05-Jul-10 9:11 PM, Sasha Khapyorsky wrote:
> On 11:10 Thu 24 Jun     , Yevgeny Kliteynik wrote:
>>
>> The problem is, one of the
>> fields in struct osm_event_plugin is called "delete".
>> Changing it to "destroy" and promoting the API version.
>
> This will break any existing plugin now (I know at least couple). I
> don't think that such change is appropriate for "between RCs" period.

OK, no problem - this can be applied after the next
management tarball and after OFED 1.5.2 release.

-- Yevgeny
  
> Sasha
>
>> Signed-off-by: Yevgeny Kliteynik<kliteyn-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html