Searched hist:"966 bae33" (Results 1 – 2 of 2) sorted by relevance
| /linux/net/mpls/ |
| H A D | internal.h | 966bae33 Wed Mar 04 01:13:19 GMT 2015 Eric W. Biederman <ebiederm@xmission.com> mpls: Functions for reading and wrinting mpls labels over netlink
Reading and writing addresses in network byte order in netlink is
traditional and I see no reason to change that. MPLS is interesting
as effectively it has variabely length addresses (the MPLS label
stack). To represent these variable length addresses in netlink
I use a valid MPLS label stack (complete with stop bit).
This achieves two things: a well defined existing format is used,
and the data can be interpreted without looking at it's length.
Not needed to look at the length to decode the variable length
network representation allows existing userspace functions
such as inet_ntop to be used without needed to change their
prototype.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| H A D | af_mpls.c | 966bae33 Wed Mar 04 01:13:19 GMT 2015 Eric W. Biederman <ebiederm@xmission.com> mpls: Functions for reading and wrinting mpls labels over netlink
Reading and writing addresses in network byte order in netlink is
traditional and I see no reason to change that. MPLS is interesting
as effectively it has variabely length addresses (the MPLS label
stack). To represent these variable length addresses in netlink
I use a valid MPLS label stack (complete with stop bit).
This achieves two things: a well defined existing format is used,
and the data can be interpreted without looking at it's length.
Not needed to look at the length to decode the variable length
network representation allows existing userspace functions
such as inet_ntop to be used without needed to change their
prototype.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|