Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation

[David Howells <dhowells@redhat.com>]

YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> wrote:

> Because it is protocol (such as ipv4 or ipv6) dependent.

Hmmm...  I had thought of RxRPC being very transport dependent, being rather
tied to UDPv4, though probably simply extensible to UDPv6.  However, as long
as the transport-layer header is removed on received packets before the main
part of the code sees them, there shouldn't be any problem supporting non-UDP
protocols, apart from, possibly, network error (ICMP) handling.

Some of the AFS operations, however, only deal in IPv4 addresses.  I believe
there is work afoot to deal with this, but I as far as I know it hasn't been
dealt with yet.

Currently RxRPC is *only* available over UDPv4 in OpenAFS as far as I know.

> You cannot use different sturcture for one address family.
> You could use union, maybe.

I am using a union:

	struct sockaddr_rxrpc {
		sa_family_t	srx_family;
		u16		srx_service;
		u16		transport_type;
		u16		transport_len;
		union {
			sa_family_t family;
			struct sockaddr_in sin;
			struct sockaddr_in6 sin6;
		} transport;
	};

I can add the alignment restrictor to the union though.

> Another option would be to introduce new transport protocol such as
> dccp or sctp, no?

It's not my choice.  My code must interoperate with the other RxRPC/AFS
implementations that are already out there and have been around for many
years.

David