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
prev parent 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 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.