On Wed, Jan 18, 2017 at 12:24 PM, Damjan Marion <dmarion.li...@gmail.com>
wrote:
>
> I see.
>
> But how come vat doesn't do this [msg ID mapping] step?
>
> Likely somebody needs to do the work…
>
> Thanks,
> Damjan
>
Ed,
As I indicated when we spoke, I have implemented the gunky details
of establishing the mapping from <msg-name_crc> to API msg ID.
It turned out to be a bit less gross than I had anticipated, primarily
due to the fact that we have separate compilation within our client
of different functional areas.
Executive summary: It is working.
Homework: Details are below if someone wants to add something
like it to, say, vat.
HTH,
jdl
--------------- sparse details -------------
So, for example, within our interface code, I added these bits:
#define vl_msg_name_crc_list
#include <vnet/interface.api.h>
#undef vl_msg_name_crc_list
and then in our intf_init() function, these bits:
#define _(msg_id, name, crc) \
vpp_set_msg_id_map(msg_id, #name "_" #crc);
foreach_vl_msg_name_crc_interface;
#undef _
That function, vpp_set_msg_id_map() establishes entries in
a global structure:
struct vpp_msg_map {
u32 id;
char *name_crc;
} vmid_map[];
using basically:
id = vl_api_get_msg_index((u8 *)name_crc);
vmid_map[msg_id].id = id;
vmid_map[msg_id].name_crc = strdup(name_crc);
Naturally, the vl_msg_api_set_handlers() calls have to do a
map lookup to get the new API msg id, like this:
#define _(N,n) \
vl_msg_api_set_handlers(vmid_map[VL_API_##N].id, \
#n, \
vl_api_##n##_t_handler, \
vl_noop_handler, \
vl_api_##n##_t_endian, \
vl_api_##n##_t_print, \
sizeof(vl_api_##n##_t), 1);
foreach_vpe_api_reply_msg;
#undef _
I buried the map lookup in the message alloc function, so then
the rest of the code can just use, say, SW_INTERFACE_DUMP
as it was already written.
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
