[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <22288.1171028743@redhat.com>
Date: Fri, 09 Feb 2007 13:45:43 +0000
From: David Howells <dhowells@...hat.com>
To: YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
Cc: dhowells@...hat.com, davem@...emloft.net, netdev@...r.kernel.org,
herbert.xu@...hat.com, hch@...radead.org, arjan@...radead.org
Subject: Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation
YOSHIFUJI Hideaki <yoshfuji@...ux-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
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists