opensm: event plig-in API fixed to compile with g++
PATCH 1/1 opensm: event plig-in API fixed to compile with g++
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.
--- 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(-)
opensm/include/opensm/osm_event_plugin.h +1 -1
@@ -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 ;
opensm/opensm/osm_event_plugin.c +2 -2
@@ -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);
opensm/osmeventplugin/libosmeventplugin.ver +1 -1
@@ -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
opensm/osmeventplugin/src/osmeventplugin.c +1 -1
@@ -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 };
Signature · 6 lines
1.5.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 4C2312F0.8020308-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org
RDMA synchronous operations
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/[email protected]
Cell: +39 3488245552
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 964270.1277390217198.SLOX.WebMail.wwwrun-XDIR3SKYeFbgKi2NxijLtw@public.gmane.org
Re: RDMA synchronous operations
Hi.
Quoted 20 lines · 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_startis before loop andt_endis 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.
Quoted 7 lines
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_sendandpost_receiveoperation 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 2 lines · Yevgeny Kliteynik
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.
Quoted 3 lines
The problem is, one of the
fields in structosm_event_pluginis 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
Quoted 66 lines
Signed-off-by Yevgeny Kliteynik <[email protected]>--- 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(-)opensm/include/opensm/osm_event_plugin.h +1
-1@@ -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 ;opensm/opensm/osm_event_plugin.c +2
-2@@ -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);opensm/osmeventplugin/libosmeventplugin.ver +1
-1@@ -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:0opensm/osmeventplugin/src/osmeventplugin.c +1
-1@@ -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 };Signature · 6 lines
1.5.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines · Sasha Khapyorsky
Quoted 2 lines · Yevgeny Kliteynik
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): AANLkTilUABmkKA8W-vIVWyTuDR8Gte9jtxmDUL1SiAte-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 9 lines · Hal Rosenstock
Quoted 5 lines · Sasha Khapyorsky
Quoted 2 lines · Yevgeny Kliteynik
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 11 lines · Sasha Khapyorsky
Quoted 9 lines · Hal Rosenstock
Quoted 5 lines · Sasha Khapyorsky
Quoted 2 lines · Yevgeny Kliteynik
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 ?
Quoted 7 lines
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
Quoted 3 lines
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): AANLkTina2lO8M65L465jXjO1ukaAudUO1ZNk8opfKtQc-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 3 lines · Hal Rosenstock
Seems to me like being able to build plugins in C++ would be very useful
For what it should be useful? Any example?
Quoted 2 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · Sasha Khapyorsky
Quoted 3 lines · Hal Rosenstock
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.
Quoted 5 lines
Quoted 2 lines
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
Quoted 6 lines
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): AANLkTinWEuCtSSfVc1Ti0SjgmUl3vnEY-DDd1nkWtlne-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
PiA+IE9wZW5TTSBpcyB3cml0dGVuIGluIEMsIG5vdCBDKyssIEknbSBwcmV0dHkgZmluZSB3aXRo IGl0IGFuZCBkb24ndCBzZWUNCj4gPiBhbnkgcmVhc29uIHRvIGdldCBDKysgZGlyZWN0aW9uLg0K PiANCj4gVGhhdCdzIE9wZW5TTSBidXQgd2h5IGxpbWl0IHBsdWcgaW4gd3JpdGVycyB0byBDID8N Cg0KRldJVywgSSBhZ3JlZSB3aXRoIEhhbC4gIFN1cHBvcnQgZm9yIGV4dGVybmFsIHBsdWctaW5z IHdyaXR0ZW4gaW4gQysrIHNlZW1zIGRlc2lyYWJsZS4NCg==
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): CF9C39F99A89134C9CF9C4CCB68B8DDF25A116CA8F-osO9UTpF0USkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org
Quoted 1 line
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.
Signature · 6 lines
Roland Dreier <[email protected]> || 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): adamxu4mtov.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org
Quoted 4 lines · Roland Dreier
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 10 lines · Sasha Khapyorsky
Quoted 4 lines · Roland Dreier
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.
Quoted 2 lines
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.
Quoted 3 lines
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
Quoted 2 lines
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · On Mon, 5 Jul 2010 11:41:44 -0700 Sasha Khapyorsky…
Quoted 5 lines · Hal Rosenstock
Quoted 4 lines · Sasha Khapyorsky
Quoted 2 lines · Yevgeny Kliteynik
Event API should have been able to be used by libraries written both in C and C++.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
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
Quoted 11 lines
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 [email protected] 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 14 lines · Ira Weiny
Quoted 11 lines · On Mon, 5 Jul 2010 11:41:44 -0700 Sasha Khapyorsky<sashak-smomgflXvOZWk0Htik3J/…
Quoted 9 lines · Hal Rosenstock
Quoted 5 lines · Sasha Khapyorsky
Quoted 2 lines · Yevgeny Kliteynik
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 ?
Quoted 8 lines
Quoted 3 lines
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
Quoted 46 lines
10:28:14> pwd; grep "
BEGIN_C_DECLSextern" */home/weiny2/OpenIB/git-trees/management/opensm/include/opensmosm_attrib_req.h:# defineBEGIN_C_DECLSextern "C" { osm_base.h:# defineBEGIN_C_DECLSextern "C" { osm_console.h:# defineBEGIN_C_DECLSextern "C" { osm_console_io.h:# defineBEGIN_C_DECLSextern "C" { osm_db.h:# defineBEGIN_C_DECLSextern "C" { osm_db_pack.h:# defineBEGIN_C_DECLSextern "C" { osm_event_plugin.h:# defineBEGIN_C_DECLSextern "C" { osm_helper.h:# defineBEGIN_C_DECLSextern "C" { osm_inform.h:# defineBEGIN_C_DECLSextern "C" { osm_lid_mgr.h:# defineBEGIN_C_DECLSextern "C" { osm_log.h:# defineBEGIN_C_DECLSextern "C" { osm_mad_pool.h:# defineBEGIN_C_DECLSextern "C" { osm_madw.h:# defineBEGIN_C_DECLSextern "C" { osm_mcast_tbl.h:# defineBEGIN_C_DECLSextern "C" { osm_mcm_port.h:# defineBEGIN_C_DECLSextern "C" { osm_msgdef.h:# defineBEGIN_C_DECLSextern "C" { osm_mtree.h:# defineBEGIN_C_DECLSextern "C" { osm_multicast.h:# defineBEGIN_C_DECLSextern "C" { osm_node.h:# defineBEGIN_C_DECLSextern "C" { osm_opensm.h:# defineBEGIN_C_DECLSextern "C" { osm_partition.h:# defineBEGIN_C_DECLSextern "C" { osm_path.h:# defineBEGIN_C_DECLSextern "C" { osm_perfmgr_db.h:# defineBEGIN_C_DECLSextern "C" { osm_pkey.h:# defineBEGIN_C_DECLSextern "C" { osm_port.h:# defineBEGIN_C_DECLSextern "C" { osm_port_profile.h:# defineBEGIN_C_DECLSextern "C" { osm_prefix_route.h:# defineBEGIN_C_DECLSextern "C" { osm_remote_sm.h:# defineBEGIN_C_DECLSextern "C" { osm_router.h:# defineBEGIN_C_DECLSextern "C" { osm_sa.h:# defineBEGIN_C_DECLSextern "C" { osm_sa_mad_ctrl.h:# defineBEGIN_C_DECLSextern "C" { osm_service.h:# defineBEGIN_C_DECLSextern "C" { osm_sm.h:# defineBEGIN_C_DECLSextern "C" { osm_sm.h.orig:# defineBEGIN_C_DECLSextern "C" { osm_sm_mad_ctrl.h:# defineBEGIN_C_DECLSextern "C" { osm_stats.h:# defineBEGIN_C_DECLSextern "C" { osm_subnet.h:# defineBEGIN_C_DECLSextern "C" { osm_subnet.h.orig:# defineBEGIN_C_DECLSextern "C" { osm_switch.h:# defineBEGIN_C_DECLSextern "C" { osm_ucast_cache.h:# defineBEGIN_C_DECLSextern "C" { osm_ucast_mgr.h:# defineBEGIN_C_DECLSextern "C" { osm_vl15intf.h:# defineBEGIN_C_DECLSextern "C" { st.h:# defineBEGIN_C_DECLSextern "C" {
Quoted 14 lines
Ira
Quoted 11 lines
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 [email protected] 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 8 lines · Sasha Khapyorsky
Quoted 4 lines · Yevgeny Kliteynik
The problem is, one of the
fields in structosm_event_pluginis 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
Quoted 3 lines
Sasha
Quoted 1 line
Signed-off-by Yevgeny Kliteynik<[email protected]>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html