From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
To: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Cc: netdev@vger.kernel.org, santosh.shilimkar@oracle.com,
davem@davemloft.net, rds-devel@oss.oracle.com
Subject: Re: [PATCH v3 net-next 0/3] rds: IPv6 support
Date: Tue, 17 Jul 2018 07:27:28 -0400 [thread overview]
Message-ID: <20180717112720.GA25197@oracle.com> (raw)
In-Reply-To: <954b0239-5d03-997c-d242-cbbd8c0dc8e4@oracle.com>
On (07/17/18 13:32), Ka-Cheong Poon wrote:
>
> The app can use either structures to make the call. When the
> app fills in the structure, it knows what it is filling in,
> either sockaddr_in or sockaddr_in6. So it knows the right size
> to use. The app can also use IPv4 mapped address in a sockaddr_in6
> without a problem.
tupical applications that I have seen in routing applicaitons
will use a union like
union {
struct sockaddr_in sin;
struct sockaddr_in sin5;
}
Or they will use sockadd_storage. Passing down the sizeoof that structure
will do the worng thing thing in the existing code for ipv4 (even
though it will not generate EFAOIT)..
> Could you please explain the inconsistency? An app can use IPv4
> mapped address in a sockaddr_in6 to operate on an IPv4 connection,
> in case you are thinking of this new addition in v3 of the patch.
bind() and connect() are using the sa_family/ss_family to have
the application signal to the kernel about whether ipv4 or ipv6 is
desired. (and bind and connect are doing the right thing for
v4mapped, so that doesnt seem to be a problem there)
In this case you want the application to signal that info via
the optlen. (And the reason for this inconsistency is that you dont
want to deal with the user->kernel copy in the same way?)
--Sowmini
next prev parent reply other threads:[~2018-07-17 11:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-13 11:02 [PATCH v3 net-next 0/3] rds: IPv6 support Ka-Cheong Poon
2018-07-13 11:02 ` [PATCH v3 net-next 1/3] rds: Changing IP address internal representation to struct in6_addr Ka-Cheong Poon
2018-07-13 11:02 ` [PATCH v3 net-next 2/3] rds: Enable RDS IPv6 support Ka-Cheong Poon
2018-07-16 9:52 ` kbuild test robot
2018-07-13 11:02 ` [PATCH v3 net-next 3/3] rds: Extend RDS API for " Ka-Cheong Poon
2018-07-13 11:18 ` 吉藤英明
2018-07-13 21:25 ` David Miller
2018-07-13 22:00 ` Santosh Shilimkar
2018-07-13 23:27 ` David Miller
2018-07-13 23:31 ` Santosh Shilimkar
2018-07-16 16:20 ` [PATCH v3 net-next 0/3] rds: " Sowmini Varadhan
2018-07-17 5:32 ` Ka-Cheong Poon
2018-07-17 11:27 ` Sowmini Varadhan [this message]
2018-07-18 7:19 ` Ka-Cheong Poon
2018-07-18 10:33 ` Sowmini Varadhan
2018-07-18 17:31 ` David Miller
2018-07-19 3:10 ` Ka-Cheong Poon
2018-07-18 17:42 ` Santosh Shilimkar
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=20180717112720.GA25197@oracle.com \
--to=sowmini.varadhan@oracle.com \
--cc=davem@davemloft.net \
--cc=ka-cheong.poon@oracle.com \
--cc=netdev@vger.kernel.org \
--cc=rds-devel@oss.oracle.com \
--cc=santosh.shilimkar@oracle.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).