All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: vladislav.yasevich@hp.com
Cc: chuck.lever@oracle.com, netdev@vger.kernel.org
Subject: Re: IPv6 address printf format specifier
Date: Wed, 18 Mar 2009 18:58:26 -0700 (PDT)	[thread overview]
Message-ID: <20090318.185826.221840814.davem@davemloft.net> (raw)
In-Reply-To: <49BE889C.8080602@hp.com>

From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Mon, 16 Mar 2009 13:13:00 -0400

> Chuck Lever wrote:
> > The NFS and RPC code in the kernel now uses the new printf format
> > specifier for IPv6 addresses.  In some cases, the generated address
> > string is sent out of the kernel (for example, it is used to build a
> > universal address for RPCB_SET requests, and used as the mon_name in
> > some SM_MON upcalls to our rpc.statd).
> > 
> > The problem is that outside the kernel, applications generally use
> > getnameinfo(3) or inet_ntop(3) to do this conversion.  The library
> > follows the RFC suggestion of shortening these address strings by
> > replacing the longest series of zeroes in the IPv6 address with "::".
> > 
> > Since the kernel doesn't do that, string comparisons don't work when
> > comparing address strings that came from our kernel.  Since these
> > address strings appear to other hosts (via the rpcbind registry) this
> > is, or could become, an interoperability issue for Linux.
> > 
> > How should I fix this?
> > 
> > 1.  Copy glibc's code to the printf logic for %pI6
> 
> I think this is the optimum solution.  This normalizes kernel output
> with that of user-space thus creating a uniform format.
> 
> My $0.02

Then you'll break cases where this string is output via
some /proc/ file or whatever and it expects the existing
behavior.

I don't think we can do this.

  reply	other threads:[~2009-03-19  1:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-16 16:24 IPv6 address printf format specifier Chuck Lever
2009-03-16 17:13 ` Vlad Yasevich
2009-03-19  1:58   ` David Miller [this message]
2009-03-19  2:26     ` Vlad Yasevich
2009-03-19  5:30       ` David Miller
2009-03-19 16:11         ` Chuck Lever

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=20090318.185826.221840814.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=chuck.lever@oracle.com \
    --cc=netdev@vger.kernel.org \
    --cc=vladislav.yasevich@hp.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 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.