Add format specifiers for printing out colon-separated bytes:
MAC addresses (%pM):
xx:xx:xx:xx:xx:xx
IPv4 addresses (%p4):
xx:xx:xx:xx
IPv6 addresses (%p6):
xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
%#pM, %#p4, %#p6 are also supported and print without the colon
separators.
[Based on Johannes Berg's initial patch]
Signed-off-by: Harvey Harrison <[email protected]>
---
This one without the embarrassing index typos in ip6_address and mac_address.
lib/vsprintf.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index a013bbc..eec3879 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -581,6 +581,58 @@ static char *resource_string(char *buf, char *end, struct resource *res, int fie
return string(buf, end, sym, field_width, precision, flags);
}
+static char *ip4_address(char *buf, char *end, u8 *addr, int field_width,
+ int precision, int flags)
+{
+ char ip4_addr[4 * 3]; /* (4 * 2 hex digits), 3 colons and trailing zero */
+ char *p = ip4_addr;
+ int i;
+
+ for (i = 0; i < 4; i++) {
+ p = pack_hex_byte(p, addr[i]);
+ if (!(flags & SPECIAL) && i != 3)
+ *p++ = ':';
+ }
+ *p = '\0';
+
+ return string(buf, end, ip4_addr, field_width, precision, flags & ~SPECIAL);
+}
+
+static char *ip6_address(char *buf, char *end, u8 *addr, int field_width,
+ int precision, int flags)
+{
+ char ip6_addr[8 * 5]; /* (8 * 4 hex digits), 7 colons and trailing zero */
+ char *p = ip6_addr;
+ int i;
+
+ for (i = 0; i < 8; i++) {
+ p = pack_hex_byte(p, addr[2 * i]);
+ p = pack_hex_byte(p, addr[2 * i + 1]);
+ if (!(flags & SPECIAL) && i != 7)
+ *p++ = ':';
+ }
+ *p = '\0';
+
+ return string(buf, end, ip6_addr, field_width, precision, flags & ~SPECIAL);
+}
+
+static char *mac_address(char *buf, char *end, u8 *addr, int field_width,
+ int precision, int flags)
+{
+ char mac_addr[6 * 3]; /* (6 * 2 hex digits), 5 colons and trailing zero */
+ char *p = mac_addr;
+ int i;
+
+ for (i = 0; i < 6; i++) {
+ p = pack_hex_byte(p, addr[i]);
+ if (!(flags & SPECIAL) && i != 5)
+ *p++ = ':';
+ }
+ *p = '\0';
+
+ return string(buf, end, mac_addr, field_width, precision, flags & ~SPECIAL);
+}
+
/*
* Show a '%p' thing. A kernel extension is that the '%p' is followed
* by an extra set of alphanumeric characters that are extended format
@@ -592,6 +644,12 @@ static char *resource_string(char *buf, char *end, struct resource *res, int fie
* - 'S' For symbolic direct pointers
* - 'R' For a struct resource pointer, it prints the range of
* addresses (not the name nor the flags)
+ * - 'M' For a 6-byte MAC address, it prints the address in the
+ * usual colon-separated hex notation
+ * - '4' For a 4-byte IPv4 address, it prints the address in the
+ * usual colon-separated hex notation
+ * - 'M' For a 16-byte IPv6 address, it prints the address in colon separated
+ * big-endian 16 bit hex notation
*
* Note: The difference between 'S' and 'F' is that on ia64 and ppc64
* function pointers are really function descriptors, which contain a
@@ -607,6 +665,12 @@ static char *pointer(const char *fmt, char *buf, char *end, void *ptr, int field
return symbol_string(buf, end, ptr, field_width, precision, flags);
case 'R':
return resource_string(buf, end, ptr, field_width, precision, flags);
+ case 'M':
+ return mac_address(buf, end, ptr, field_width, precision, flags);
+ case '4':
+ return ip4_address(buf, end, ptr, field_width, precision, flags);
+ case '6':
+ return ip6_address(buf, end, ptr, field_width, precision, flags);
}
flags |= SMALL;
if (field_width == -1) {
--
1.6.0.3.729.g6ea410
Harvey Harrison wrote:
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index a013bbc..eec3879 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -592,6 +644,12 @@ static char *resource_string(char *buf, char *end,
> struct resource *res, int fie
> * - 'S' For symbolic direct pointers
> * - 'R' For a struct resource pointer, it prints the range of
> * addresses (not the name nor the flags)
> + * - 'M' For a 6-byte MAC address, it prints the address in the
> + * usual colon-separated hex notation
> + * - '4' For a 4-byte IPv4 address, it prints the address in the
> + * usual colon-separated hex notation
> + * - 'M' For a 16-byte IPv6 address, it prints the address in colon separated
> + * big-endian 16 bit hex notation
Shouldn't that last one be '6' instead of 'M'?
Frans Pop wrote:
>> + * - '4' For a 4-byte IPv4 address, it prints the address in the
>> + * usual colon-separated hex notation
Since when are IPv4 addresses "usually" printed in colon-separated hex?
-hpa
On Sun, 2008-10-26 at 17:31 -0700, Harvey Harrison wrote:
> Add format specifiers for printing out colon-separated bytes:
>
> MAC addresses (%pM):
> xx:xx:xx:xx:xx:xx
>
> IPv4 addresses (%p4):
> xx:xx:xx:xx
As hpa points out, the usual notation would be %d.%d.%d.%d :)
> %#pM, %#p4, %#p6 are also supported and print without the colon
> separators.
The # for ipv4 we might use for cpu-endian rather than network-endian
maybe?
Also can you keep mac/ip address patches split up so we can use my
version of the mac address patch (it's already well-tested)?
johannes
On Mon, 2008-10-27 at 07:59 +0100, Johannes Berg wrote:
> Also can you keep mac/ip address patches split up so we can use my
> version of the mac address patch (it's already well-tested)?
>
Sure. I'll build on top.
Harvey
From: Harvey Harrison <[email protected]>
Date: Mon, 27 Oct 2008 09:28:24 -0700
> On Mon, 2008-10-27 at 07:59 +0100, Johannes Berg wrote:
>
> > Also can you keep mac/ip address patches split up so we can use my
> > version of the mac address patch (it's already well-tested)?
> >
>
> Sure. I'll build on top.
So I'll wait for Harvey's "v3" of this patch, and once I have that in
the net-next-2.6 tree I'll start adding Johannes's conversions on top.
On Mon, 2008-10-27 at 12:38 -0700, David Miller wrote:
> From: Harvey Harrison <[email protected]>
> Date: Mon, 27 Oct 2008 09:28:24 -0700
>
> > On Mon, 2008-10-27 at 07:59 +0100, Johannes Berg wrote:
> >
> > > Also can you keep mac/ip address patches split up so we can use my
> > > version of the mac address patch (it's already well-tested)?
> > >
> >
> > Sure. I'll build on top.
>
> So I'll wait for Harvey's "v3" of this patch, and once I have that in
> the net-next-2.6 tree I'll start adding Johannes's conversions on top.
Ok, fine with me too. Harvey, can you sort out the ip4 issue and then
send with %pM included?
johannes
Add format specifiers for printing out six colon-separated bytes:
MAC addresses (%pM):
xx:xx:xx:xx:xx:xx
%#pM is also supported and omits the colon separators.
Signed-off-by: Harvey Harrison <[email protected]>
---
Dave, this passes testing here, but I was wondering if perhaps it would be
better to allow a length to be specified as well, which would allow:
%pM6 for mac addresses, etc as there seem a lot of places in kernel that
print out a list of colon separated bytes of various lengths.
But if that was added, it may be more natural to call it
%pB (bytes)
%pW (words)
Then mac addresses would be %pB6
IPv6 addresses would be %pW8 (8 words)
It would be trivial to add, but maybe I'm overthinking this. In any event,
this patch only adds %pM for mac addresses.
lib/vsprintf.c | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index a013bbc..2025305 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -581,6 +581,23 @@ static char *resource_string(char *buf, char *end, struct resource *res, int fie
return string(buf, end, sym, field_width, precision, flags);
}
+static char *mac_address(char *buf, char *end, u8 *addr, int field_width,
+ int precision, int flags)
+{
+ char mac_addr[6 * 3]; /* (6 * 2 hex digits), 5 colons and trailing zero */
+ char *p = mac_addr;
+ int i;
+
+ for (i = 0; i < 6; i++) {
+ p = pack_hex_byte(p, addr[i]);
+ if (!(flags & SPECIAL) && i != 5)
+ *p++ = ':';
+ }
+ *p = '\0';
+
+ return string(buf, end, mac_addr, field_width, precision, flags & ~SPECIAL);
+}
+
/*
* Show a '%p' thing. A kernel extension is that the '%p' is followed
* by an extra set of alphanumeric characters that are extended format
@@ -592,6 +609,8 @@ static char *resource_string(char *buf, char *end, struct resource *res, int fie
* - 'S' For symbolic direct pointers
* - 'R' For a struct resource pointer, it prints the range of
* addresses (not the name nor the flags)
+ * - 'M' For a 6-byte MAC address, it prints the address in the
+ * usual colon-separated hex notation
*
* Note: The difference between 'S' and 'F' is that on ia64 and ppc64
* function pointers are really function descriptors, which contain a
@@ -607,6 +626,8 @@ static char *pointer(const char *fmt, char *buf, char *end, void *ptr, int field
return symbol_string(buf, end, ptr, field_width, precision, flags);
case 'R':
return resource_string(buf, end, ptr, field_width, precision, flags);
+ case 'M':
+ return mac_address(buf, end, ptr, field_width, precision, flags);
}
flags |= SMALL;
if (field_width == -1) {
--
1.6.0.3.729.g6ea410
On Mon, 2008-10-27 at 12:59 -0700, Harvey Harrison wrote:
The changes to use %p4 aren't too bad.
I did that last year using a similar style
to print_mac. 80 or so files.
http://repo.or.cz/w/linux-2.6/trivial-mods.git?a=shortlog;h=refs/heads/print_ipv4
ipv6 was 30 or so files
http://repo.or.cz/w/linux-2.6/trivial-mods.git?a=shortlog;h=refs/heads/print_ipv6
> I was wondering if perhaps it would be
> better to allow a length to be specified as well, which would allow:
[]
> But if that was added, it may be more natural to call it
> %pB (bytes)
> %pW (words)
I think length would not be good addition.
print_dump_hex already does a fine job.
There are also BE/LE expectation problems with pW.
The %p6 pointer should be in6_addr *
The %p4 pointer should be __be32 *.
Printing an ipv4 address should use %u.%u.%u.%u
I've been doodling with sparse to check
calls with __attribute__(format(printf
parsing the format strings for %p<FOO>
and match the argument types.
I'll post it if anything comes of it.
> +static char *mac_address(char *buf, char *end, u8 *addr, int field_width,
> + int precision, int flags)
> +{
mac_address_string please.
From: Joe Perches <[email protected]>
Date: Mon, 27 Oct 2008 14:55:15 -0700
> On Mon, 2008-10-27 at 12:59 -0700, Harvey Harrison wrote:
>
> > +static char *mac_address(char *buf, char *end, u8 *addr, int field_width,
> > + int precision, int flags)
> > +{
>
> mac_address_string please.
I'll make this change when I apply Harvey's patch.
From: Harvey Harrison <[email protected]>
Date: Mon, 27 Oct 2008 12:59:02 -0700
> Add format specifiers for printing out six colon-separated bytes:
>
> MAC addresses (%pM):
> xx:xx:xx:xx:xx:xx
>
> %#pM is also supported and omits the colon separators.
>
> Signed-off-by: Harvey Harrison <[email protected]>
Applied, thanks.
On Mon, 2008-10-27 at 15:47 -0700, David Miller wrote:
> From: Harvey Harrison <[email protected]>
> Date: Mon, 27 Oct 2008 12:59:02 -0700
>
> > Add format specifiers for printing out six colon-separated bytes:
> >
> > MAC addresses (%pM):
> > xx:xx:xx:xx:xx:xx
> >
> > %#pM is also supported and omits the colon separators.
> >
> > Signed-off-by: Harvey Harrison <[email protected]>
>
> Applied, thanks.
Did you happen to have a preference with regard to the specifier for
IPv6 addresses:
I was thinking of using %pI6 to replace NIP6() and NIP6_FMT and using
%#pI6 for NIP6_SEQFMT.
On the IPv4 side, maybe use %pI4 for network endian NIPQUAD() and NIPQUAD_FMT
and then %#pI4 for host-endian HIQUAD(), as displaying the IPv4 address without
the periods isn't useful?
What do you think of that?
Harvey
On Mon, Oct 27, 2008 at 04:14:14PM -0700, Harvey Harrison wrote:
> On Mon, 2008-10-27 at 15:47 -0700, David Miller wrote:
> > From: Harvey Harrison <[email protected]>
> > Date: Mon, 27 Oct 2008 12:59:02 -0700
> >
> > > Add format specifiers for printing out six colon-separated bytes:
> > >
> > > MAC addresses (%pM):
> > > xx:xx:xx:xx:xx:xx
> > >
> > > %#pM is also supported and omits the colon separators.
> > >
> > > Signed-off-by: Harvey Harrison <[email protected]>
> >
> > Applied, thanks.
>
> Did you happen to have a preference with regard to the specifier for
> IPv6 addresses:
>
> I was thinking of using %pI6 to replace NIP6() and NIP6_FMT and using
> %#pI6 for NIP6_SEQFMT.
>
> On the IPv4 side, maybe use %pI4 for network endian NIPQUAD() and NIPQUAD_FMT
> and then %#pI4 for host-endian HIQUAD(), as displaying the IPv4 address without
> the periods isn't useful?
%#pI4 is horrible and %p4 and %p6 were cool.
On Mon, 2008-10-27 at 16:14 -0700, Harvey Harrison wrote:
> I was thinking of using %pI6 to replace NIP6() and NIP6_FMT and using
> %#pI6 for NIP6_SEQFMT.
>
> On the IPv4 side, maybe use %pI4 for network endian NIPQUAD() and NIPQUAD_FMT
> and then %#pI4 for host-endian HIQUAD(), as displaying the IPv4 address without
> the periods isn't useful?
HIPQUAD is horrible and should disappear.
Just use htonl first.
I think just %p4 %p6 %#p6 for the NIP6_SEQFMT uses.
From: Harvey Harrison <[email protected]>
Date: Mon, 27 Oct 2008 16:14:14 -0700
> Did you happen to have a preference with regard to the specifier for
> IPv6 addresses:
>
> I was thinking of using %pI6 to replace NIP6() and NIP6_FMT and using
> %#pI6 for NIP6_SEQFMT.
>
> On the IPv4 side, maybe use %pI4 for network endian NIPQUAD() and NIPQUAD_FMT
> and then %#pI4 for host-endian HIQUAD(), as displaying the IPv4 address without
> the periods isn't useful?
>
> What do you think of that?
I'm ok with the '#' modifier but remind me again what's wrong with
using plain %p4 and %p6?
On Mon, 2008-10-27 at 16:55 -0700, David Miller wrote:
> From: Harvey Harrison <[email protected]>
> Date: Mon, 27 Oct 2008 16:14:14 -0700
>
> > Did you happen to have a preference with regard to the specifier for
> > IPv6 addresses:
> >
> > I was thinking of using %pI6 to replace NIP6() and NIP6_FMT and using
> > %#pI6 for NIP6_SEQFMT.
> >
> > On the IPv4 side, maybe use %pI4 for network endian NIPQUAD() and NIPQUAD_FMT
> > and then %#pI4 for host-endian HIQUAD(), as displaying the IPv4 address without
> > the periods isn't useful?
> >
> > What do you think of that?
>
> I'm ok with the '#' modifier but remind me again what's wrong with
> using plain %p4 and %p6?
Nothing at all, just wanted to know what color bikeshed you wanted.
I'll go with %p4 %p6.
Harvey
On Mon, 2008-10-27 at 17:05 -0700, Harvey Harrison wrote:
> On Mon, 2008-10-27 at 16:55 -0700, David Miller wrote:
> > I'm ok with the '#' modifier but remind me again what's wrong with
> > using plain %p4 and %p6?
> Nothing at all, just wanted to know what color bikeshed you wanted.
> I'll go with %p4 %p6.
Just an FYI for v6 addresses:
There are a few uses of ipv6 address as "%08X%08X%08X%08X"
Pavel Emelyanov tried to isolate them with a suggested patch:
http://www.mail-archive.com/[email protected]/msg51655.html
These addresses are not shown in network order, but are
printed backwards in host order. Oops. Apparently it's
too late to fix them.
On Mon, 2008-10-27 at 16:48 -0700, Joe Perches wrote:
> On Mon, 2008-10-27 at 16:14 -0700, Harvey Harrison wrote:
> > I was thinking of using %pI6 to replace NIP6() and NIP6_FMT and using
> > %#pI6 for NIP6_SEQFMT.
> >
> > On the IPv4 side, maybe use %pI4 for network endian NIPQUAD() and NIPQUAD_FMT
> > and then %#pI4 for host-endian HIQUAD(), as displaying the IPv4 address without
> > the periods isn't useful?
>
> HIPQUAD is horrible and should disappear.
> Just use htonl first.
But you can't really say
printk("... %p4 ...", &htonl(host_ip4));
can you? I suppose the compiler would actually create a variable for
that?
johannes
On Mon, 2008-10-27 at 17:22 -0700, Joe Perches wrote:
> On Mon, 2008-10-27 at 17:05 -0700, Harvey Harrison wrote:
> > On Mon, 2008-10-27 at 16:55 -0700, David Miller wrote:
> > > I'm ok with the '#' modifier but remind me again what's wrong with
> > > using plain %p4 and %p6?
> > Nothing at all, just wanted to know what color bikeshed you wanted.
> > I'll go with %p4 %p6.
>
> Just an FYI for v6 addresses:
>
> There are a few uses of ipv6 address as "%08X%08X%08X%08X"
> Pavel Emelyanov tried to isolate them with a suggested patch:
>
> http://www.mail-archive.com/[email protected]/msg51655.html
>
> These addresses are not shown in network order, but are
> printed backwards in host order. Oops. Apparently it's
> too late to fix them.
So that code we don't touch here at all.
johannes