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

2010-07-08 Thread Hal Rosenstock 
On Wed, Jul 7, 2010 at 9:58 AM, Sasha Khapyorsky sas...@voltaire.com 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2010-07-07 Thread 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2010-07-06 Thread 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 rola...@cisco.com || 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2010-07-06 Thread Ira Weiny 
On Mon, 5 Jul 2010 11:41:44 -0700
Sasha Khapyorsky sas...@voltaire.com wrote:

 On 14:30 Mon 05 Jul , Hal Rosenstock wrote:
  On Mon, Jul 5, 2010 at 2:11 PM, Sasha Khapyorsky sas...@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 majord...@vger.kernel.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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2010-07-06 Thread Yevgeny Kliteynik 

On 07-Jul-10 12:03 AM, Ira Weiny wrote:

On Mon, 5 Jul 2010 11:41:44 -0700
Sasha Khapyorskysas...@voltaire.com  wrote:


On 14:30 Mon 05 Jul , Hal Rosenstock wrote:

On Mon, Jul 5, 2010 at 2:11 PM, Sasha Khapyorskysas...@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++.


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 majord...@vger.kernel.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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2010-07-05 Thread 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 klit...@dev.mellanox.co.il
 ---
  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 majord...@vger.kernel.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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2010-07-05 Thread Hal Rosenstock 
On Mon, Jul 5, 2010 at 2:11 PM, Sasha Khapyorsky sas...@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 ?

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

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

2010-07-05 Thread Sasha Khapyorsky 
On 14:30 Mon 05 Jul , Hal Rosenstock wrote:
 On Mon, Jul 5, 2010 at 2:11 PM, Sasha Khapyorsky sas...@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++.

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2010-07-05 Thread Hal Rosenstock 
On Mon, Jul 5, 2010 at 6:52 PM, Sasha Khapyorsky sas...@voltaire.com 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 majord...@vger.kernel.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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2010-06-24 Thread 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 klit...@dev.mellanox.co.il
---
 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html