From: David Howells <dhowells@redhat.com>
To: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Cc: dhowells@redhat.com, davem@davemloft.net, netdev@vger.kernel.org,
herbert.xu@redhat.com, hch@infradead.org, arjan@infradead.org
Subject: Re: [PATCH 0/5] [RFC] AF_RXRPC socket family implementation
Date: Fri, 09 Feb 2007 13:45:43 +0000 [thread overview]
Message-ID: <22288.1171028743@redhat.com> (raw)
In-Reply-To: <20070209.221453.16393835.yoshfuji@linux-ipv6.org>
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
next prev parent reply other threads:[~2007-02-09 13:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-08 16:32 [PATCH 0/5] [RFC] AF_RXRPC socket family implementation David Howells
2007-02-08 16:32 ` [PATCH 1/5] Add PCBC crypto template support David Howells
2007-02-08 21:32 ` Herbert Xu
2007-02-09 11:18 ` David Howells
2007-02-09 22:26 ` David Miller
2007-02-12 11:35 ` David Howells
2007-02-08 16:32 ` [PATCH 2/5] FCrypt encryption module David Howells
2007-02-08 19:20 ` Christoph Hellwig
2007-02-08 16:32 ` [PATCH 3/5] Crypto: Add blkcipher accessors for using kernel data directly David Howells
2007-02-08 16:32 ` [PATCH 4/5] Move generic skbuff stuff from XFRM code to generic code David Howells
2007-02-08 16:55 ` [PATCH 0/5] [RFC] AF_RXRPC socket family implementation YOSHIFUJI Hideaki / 吉藤英明
2007-02-08 22:01 ` David Miller
2007-02-09 10:31 ` David Howells
2007-02-09 10:37 ` YOSHIFUJI Hideaki / 吉藤英明
2007-02-09 12:31 ` David Howells
2007-02-09 13:14 ` YOSHIFUJI Hideaki / 吉藤英明
2007-02-09 13:45 ` David Howells [this message]
2007-02-22 13:02 ` David Howells
2007-03-08 22:48 David Howells
2007-03-08 22:54 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=22288.1171028743@redhat.com \
--to=dhowells@redhat.com \
--cc=arjan@infradead.org \
--cc=davem@davemloft.net \
--cc=hch@infradead.org \
--cc=herbert.xu@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.