All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Cc: 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: Thu, 22 Feb 2007 13:02:27 +0000	[thread overview]
Message-ID: <1808.1172149347@redhat.com> (raw)
In-Reply-To: <20070209.015539.53640067.yoshfuji@linux-ipv6.org>

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

> This sockaddr_rxrpc{} should NOT include sockaddr_in{} directly.
> Please use sockaddr_storage{} (or sockaddr{}, maybe), and make it
> sure to align on 64-bit word.

How about this then:

struct sockaddr_rxrpc {
	sa_family_t	srx_family;	/* address family */
	u16		srx_service;	/* service desired */
	u16		transport_type;	/* type of transport socket (SOCK_DGRAM) */
	u16		transport_len;	/* length of transport address */
	struct sockaddr	srx_sa[0];	/* address of transport endpoint */
};

Then whoever wants to use it must follow it immediately with an address of the
appropriate type.  The length given to connect or bind would then be the
combined length of the two addresses.

Someone could then set one up on the stack by this sort of thing:

	int zebra(int fd)
	{
		struct {
			struct sockaddr_rxrpc srx;
			struct sockaddr_in sin;
		} sa;

		...
		if (connect(fd, (struct sockaddr *) &sa, sizeof(sa)) < 0)
			...
		...
	}

David

  parent reply	other threads:[~2007-02-22 13:02 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
2007-02-22 13:02 ` David Howells [this message]
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=1808.1172149347@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.