linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Doug Maxey <dwm@austin.ibm.com>
Cc: Linux PowerPC List <linuxppc-dev@ozlabs.org>,
	Paul Mackerras <paulus@samba.org>,
	Paul Nasrat <pnasrat@redhat.com>,
	yaboot-devel@ozlabs.org
Subject: Re: ipv6 in yaboot
Date: Mon, 6 Aug 2007 20:42:35 +0200	[thread overview]
Message-ID: <ca5af1386c47bdf03146b1d3ac2cff39@kernel.crashing.org> (raw)
In-Reply-To: <14772.1186002066@falcon10.austin.ibm.com>

>> The network address is passed to OF as (part of) the device
>> argument for the network device; and colons aren't legal
>> characters in a device argument,
>
> yeah, pretty thoughtless of the IETF for not consulting the 1275WG. :)

Heh.  That's not an issue; it just means that OF implementations
need to use a (slightly) different spelling for IPV6 addresses.
However, see below.

>> so any OF implementation that
>> would use colons in IPv6 addresses is terminally broken.
>
> Ok.  What is your proposed resolution that does not violate the rfcs?
> Namely RFCs 3986, 4038, and especially 4291.

Quotes from those RFCs would have been helpful.

>> This
>> is completely analogous to the fact that filesystem paths cannot
>> use forward slashes.  (The third disallowed character is the
>> at-sign, for completeness).
>
> Not really.  I don't expect to the the "device path" contain any ipv6
> info.  Just the parameters that follow on the end,

There can be parameters at *any* path component though, not just
the final component.  It isn't too farfetched to imagine devices as
child devices under a network device IMHO.  Not the common case, sure.

> There is no ppc64 OFW that supports this yet, but a version is
> expected soon.

There is an x86 OFW that supports it now.  Some good news, too:

The requirement for device arguments to not contain colons or
at-signs has been deemed overly strict, since any defined use
for those arguments should follow the path resolution algorithm
that is spelled out in the specification itself; and that algorithm
can deal with it just fine.  Therefore, it now is an (unpublished :-) )
recommended practice for OF implementations to allow it.

Forward slashes are right out, though :-)

> BTW, I don't really have any real input into how the OFW is designed,
> just try to adapt to what is implemented.

Yeah I understand :-)


Segher

      reply	other threads:[~2007-08-06 18:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-31 19:21 ipv6 in yaboot Doug Maxey
2007-07-31 20:11 ` Paul Nasrat
2007-07-31 21:08   ` Doug Maxey
2007-08-01  1:03 ` Paul Mackerras
2007-08-01  2:37   ` Doug Maxey
2007-08-01  5:12     ` Segher Boessenkool
2007-08-01 21:01       ` Doug Maxey
2007-08-06 18:42         ` Segher Boessenkool [this message]

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=ca5af1386c47bdf03146b1d3ac2cff39@kernel.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=dwm@austin.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.org \
    --cc=pnasrat@redhat.com \
    --cc=yaboot-devel@ozlabs.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 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).