public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik•org>
To: Chuck Lever <chuck.lever@oracle•com>
Cc: netdev@vger•kernel.org
Subject: Re: [PATCH 0/4] RFC: raw IPv6 address parsing in NFS client
Date: Mon, 19 May 2008 14:56:20 -0400	[thread overview]
Message-ID: <4831CD54.9050004@garzik.org> (raw)
In-Reply-To: <BA7B3AE0-E0BA-4535-8641-5DC4A3A41F64@oracle.com>

Chuck Lever wrote:
> On May 18, 2008, at 10:13 PM, Jeff Garzik wrote:
>> Chuck Lever wrote:
>>> Hi-
>>> I'm interested in some review of the following four patches which add to
>>> the kernel's NFS client the ability to parse IPv6 addresses in 
>>> presentation
>>> format.
>>> Namely, it adds the following:
>>> 1.  If the user passes in an IPv6 address as the server name, the colons
>>>    in the address will confuse the logic that splits the device name
>>>    into a server hostname and an export path.   We'll use square 
>>> brackets
>>>    around IPv6 server addresses to "escape" the colons, as does Solaris.
>>> 2.  If the user passes in a link-local IPv6 address as the server name,
>>>    an interface index is also necessary.  We'll use the "%id" suffix on
>>>    the address to pass in the index, and plant that in the sockaddr's
>>>    sin6_scope_id field.
>>> In addition to the following patches in email, a git repo with these
>>> same patches already applied can be found here:
>>>     linux-nfs.org:exports/cel-2.6.git
>>> The basic questions:
>>> Are these reasonable conventions to follow?  Is the parsing logic 
>>> adequate?
>>> Is there anything I'm forgetting?
>>
>> I would take a look at the underlying components of glibc's 
>> getnameinfo(), which must parse IPv6 addresses according to POSIX 
>> specifications, IIRC.
>>
>> Comments:
>>
>> 1) bracket escaping seems reasonably common.  browsers and other apps 
>> sometimes use that convention too.
>>
>> 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.

I don't know precisely your intended usage, nor where your 
kernel/userland divide is here, but looking at dev_get_by_name() might 
be a start, for accessing netdev via ifname?

	Jeff




  reply	other threads:[~2008-05-19 18:56 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 [this message]
2008-05-19 19:46       ` Chuck Lever
2008-05-19 20:32         ` Brian Haley
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=4831CD54.9050004@garzik.org \
    --to=jeff@garzik$(echo .)org \
    --cc=chuck.lever@oracle$(echo .)com \
    --cc=netdev@vger$(echo .)kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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