All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Haley <brian.haley@hp.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Jeff Garzik <jeff@garzik.org>, netdev@vger.kernel.org
Subject: Re: [PATCH 0/4] RFC: raw IPv6 address parsing in NFS client
Date: Mon, 19 May 2008 16:32:36 -0400	[thread overview]
Message-ID: <4831E3E4.5060700@hp.com> (raw)
In-Reply-To: <7799EF8C-6BDB-4B32-ABD8-E3DF840D5195@oracle.com>

Chuck Lever wrote:
>>>> 2) an interface name rather than index should be used
>>> If you give a raw IPv6 address with an interface name to mount.nfs, 
>>> it passes the whole thing to getaddrinfo(3) which maps the name to an 
>>> index. The address with index is then passed on to the kernel via 
>>> mount(2) via the normal "addr=" mount option.
>>> Is there a way the kernel can do that mapping for itself?
>>
>> The kernel certainly knows the interface names...  IMO that is a bit 
>> more natural than interface index.
>>
>> You certainly do not want to _store_ interface index or encourage its 
>> use, since it might change during runtime if network interfaces change.
> 
> We are storing the address of the server in a struct sockaddr_storage, 
> and that would include a scope ID if it were an AF_INET6 address.  We 
> are also storing the server hostname in /etc/mtab for umount.nfs to use 
> later, and that hostname may be a raw IPv6 address.
> 
> So it sounds like we need to store the device name separately in the 
> kernel's NFS and RPC data structures and do the devname to scope_id 
> conversion during the transport's socket connect.  Oy.

Hmm, the kernel already stores interface indexes in structures today, 
for example if you use SO_BINDTODEVICE, or join a Multicast group. 
Seems to me that's perfectly valid to do, with the caveat that the 
device might change it's index.

-Brian

  reply	other threads:[~2008-05-19 20:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-18 21:19 [PATCH 0/4] RFC: raw IPv6 address parsing in NFS client Chuck Lever
2008-05-18 21:20 ` [PATCH 1/4] NFS: Use common device name parsing logic for NFSv4 and NFSv2/v3 Chuck Lever
2008-05-18 21:20 ` [PATCH 2/4] NFS: Support raw IPv6 address hostnames during NFS mount operation Chuck Lever
2008-05-18 22:23   ` Trond Myklebust
2008-05-19 14:48     ` Chuck Lever
2008-05-18 21:20 ` [PATCH 3/4] NFS: Add string length argument to nfs_parse_server_address Chuck Lever
2008-05-18 21:20 ` [PATCH 4/4] NFS: handle interface identifiers in incoming IPv6 addresses Chuck Lever
2008-05-19  2:13 ` [PATCH 0/4] RFC: raw IPv6 address parsing in NFS client Jeff Garzik
2008-05-19 14:15   ` Chuck Lever
2008-05-19 18:56     ` Jeff Garzik
2008-05-19 19:46       ` Chuck Lever
2008-05-19 20:32         ` Brian Haley [this message]
2008-05-19 17:55   ` Chuck Lever
2008-05-19 18:58     ` Jeff Garzik

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=4831E3E4.5060700@hp.com \
    --to=brian.haley@hp.com \
    --cc=chuck.lever@oracle.com \
    --cc=jeff@garzik.org \
    --cc=netdev@vger.kernel.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.