rte_channel_service_flow_osadapter.h File Reference

rte_osadapter_channel_service_t implementation over rte_flow. More...

#include "rte/redundancy/channel_service/rte_channel_service.h"
#include "rte/oal/netlink/rte_netlink.h"

Include dependency graph for rte_channel_service_flow_osadapter.h:

This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Typedefs
typedef rte_status_t(*)	rte_channel_service_flow_resolve_fn(const char *channel_name, rte_netlink_config_t *out_config, void *context)

Functions
rte_status_t	rte_channel_service_flow_osadapter_register_resolver (rte_channel_service_flow_resolve_fn resolver, void *context)
	Registers the resolver this OSAdapter calls from setup() to learn a channel name's role/host/port/message_size.
const rte_osadapter_channel_service_t *	rte_channel_service_flow_osadapter (void)
	Returns the rte_osadapter_channel_service_t vtable to pass to rte_osadapter_channel_service_register().

Detailed Description

rte_osadapter_channel_service_t implementation over rte_flow.

Added per direct request as part of the RCA/OCORA compatibility initiative's Phase 4 (see docs/rca/ at the workspace root and TODO.dox's "Platform (RCA/OCORA)" section): a real, drop-in alternative to Platform_OS_POSIX's rte_posix_osadapter_channel_service, so an integrator (e.g. RBC_GP) can route its named channels (e.g. "ab-peer", "ab-negotiate") through rte_flow (and, once a real DDS OSAdapter exists, through actual DDS) with ZERO change to its own transport-agnostic rte_channel_service_setup()/_read()/_send()/_close() call sites.

Deliberately reuses the EXACT SAME resolver function shape (rte_channel_service_flow_resolve_fn, filling a rte_netlink_config_t) Platform_OS_POSIX's own resolver does - an integrator that already has a working resolve_channel() for the POSIX OSAdapter can register the SAME function here unchanged; this OSAdapter translates rte_netlink_config_t::role into a rte_flow_oflag_t (CONNECT->PUBLISHER, LISTEN->SUBSCRIBER, matching Platform_Protocol_DDS's own oflags->role mapping in reverse) and opens exactly one Flow per channel name, used for both send and receive - full duplex on one Flow, the same shape a single netlink link already provides (verified against Platform_Protocol_DDS's own stub: rte_flow_send()/_receive() both operate on the one underlying rte_netlink_handle_t a Flow opens, regardless of which oflag it was opened with).

This module is deliberately osadapter-agnostic - it calls only rte_flow_* API, never anything specific to Platform_Protocol_DDS or any other concrete rte_osadapter_flow_t. Registering a ROUTE (mapping a channel name to host:port) for today's stub OSAdapter is the INTEGRATOR's job, done before rte_channel_service_setup() is called (e.g. inside the integrator's own resolver, which already knows which flow OSAdapter it registered) - a real DDS OSAdapter would need no such route at all (DDS topics are self-describing via discovery), so this module was kept free of that stub-specific concern on purpose.

Definition in file rte_channel_service_flow_osadapter.h.