MAC addresses may be formed using rules based on EUI-64, which is 2 bytes
longer than a typical 6-byte MAC. This patch adds a long specifier to
the %pM format to support the extended unique identifier.
Since there are multiple valid possible permutations of format specifiers,
the decoding is done in a loop, and the default ':' separator is
initialized at declaration time. A side effect of this allows 'F' and
'R' both be specified, so these are appended to the documentation.
Signed-off-by: Keith Busch <[email protected]>
---
>From previous version:
Use 'while (isalpha(*++fmt))' to loop over all the format specfiers,
and updated documentation with the new possible formats.
Documentation/printk-formats.txt | 15 ++++++++++++---
lib/vsprintf.c | 40 +++++++++++++++++++++-------------------
2 files changed, 33 insertions(+), 22 deletions(-)
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index b784c27..b39eb37 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -136,14 +136,23 @@ Raw buffer as a hex string:
MAC/FDDI addresses:
%pM 00:01:02:03:04:05
+ %pMl 00:01:02:03:04:05:06:07
%pMR 05:04:03:02:01:00
+ %pMRl 07:06:05:04:03:02:01:00
%pMF 00-01-02-03-04-05
+ %pMFl 00-01-02-03-04-05-06-07
+ %pMFR 05-04-03-02-01-00
+ %pMFRl 07-06-05-04-03-02-01-00
%pm 000102030405
+ %pml 0001020304050607
%pmR 050403020100
+ %pmRl 0706050403020100
- For printing 6-byte MAC/FDDI addresses in hex notation. The 'M' and 'm'
- specifiers result in a printed address with ('M') or without ('m') byte
- separators. The default byte separator is the colon (':').
+ For printing 6 or 8-byte MAC/FDDI addresses in hex notation. The
+ 'M' and 'm' specifiers result in a printed address with ('M')
+ or without ('m') byte separators. The default byte separator is
+ the colon (':'). Append 'l' to specify an 8-byte in accordance
+ with EUI-64 format.
Where FDDI addresses are concerned the 'F' specifier can be used after
the 'M' specifier to use dash ('-') separators instead of the default
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index f9cee8e..01b7ebd 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -889,33 +889,33 @@ static noinline_for_stack
char *mac_address_string(char *buf, char *end, u8 *addr,
struct printf_spec spec, const char *fmt)
{
- char mac_addr[sizeof("xx:xx:xx:xx:xx:xx")];
+ char mac_addr[sizeof("xx:xx:xx:xx:xx:xx:xx:xx")];
char *p = mac_addr;
- int i;
- char separator;
- bool reversed = false;
-
- switch (fmt[1]) {
- case 'F':
- separator = '-';
- break;
+ int i, bytes = 6;
+ char separator = ':';
+ bool reversed = false, separate = (fmt[0] == 'M');
- case 'R':
- reversed = true;
- /* fall through */
-
- default:
- separator = ':';
- break;
+ while (isalpha(*++fmt)) {
+ switch (*fmt) {
+ case 'F':
+ separator = '-';
+ break;
+ case 'R':
+ reversed = true;
+ break;
+ case 'l':
+ bytes = 8;
+ break;
+ }
}
- for (i = 0; i < 6; i++) {
+ for (i = 0; i < bytes; i++) {
if (reversed)
- p = hex_byte_pack(p, addr[5 - i]);
+ p = hex_byte_pack(p, addr[(bytes - 1) - i]);
else
p = hex_byte_pack(p, addr[i]);
- if (fmt[0] == 'M' && i != 5)
+ if (separate && i != (bytes - 1))
*p++ = separator;
}
*p = '\0';
@@ -1496,6 +1496,8 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
case 'm': /* Contiguous: 000102030405 */
/* [mM]F (FDDI) */
/* [mM]R (Reverse order; Bluetooth) */
+ /* [mM]l (EUI-64) */
+ /* [mM][FM]l (FDDI/Reverse order EUI-64) */
return mac_address_string(buf, end, ptr, spec, fmt);
case 'I': /* Formatted IP supported
* 4: 1.2.3.4
--
2.6.2.307.g37023ba
On Wed, 2015-12-09 at 16:06 -0700, Keith Busch wrote:
> MAC addresses may be formed using rules based on EUI-64, which is 2 bytes
> longer than a typical 6-byte MAC. This patch adds a long specifier to
> the %pM format to support the extended unique identifier.
>
> Since there are multiple valid possible permutations of format specifiers,
> the decoding is done in a loop, and the default ':' separator is
> initialized at declaration time. A side effect of this allows 'F' and
> 'R' both be specified, so these are appended to the documentation.
Just thought of this:
An alternative is using a format of "%8phC"
Is there a use case for a bluetooth or FDDI EUI-64?
> -----Original Message-----
> From: [email protected] [mailto:linux-kernel-
> [email protected]] On Behalf Of Keith Busch
> Sent: Wednesday, December 9, 2015 5:07 PM
...
> Subject: [PATCHv3] printf: Add format for 8-byte EUI-64 type
>
...
> @@ -1496,6 +1496,8 @@ char *pointer(const char *fmt, char *buf, char
> *end, void *ptr,
> case 'm': /* Contiguous: 000102030405 */
> /* [mM]F (FDDI) */
> /* [mM]R (Reverse order; Bluetooth) */
> + /* [mM]l (EUI-64) */
> + /* [mM][FM]l (FDDI/Reverse order EUI-64) */
Should that be [FR] rather than [FM]?
---
Robert Elliott, HPE Persistent Memory
On Wed, Dec 09, 2015 at 03:21:40PM -0800, Joe Perches wrote:
> On Wed, 2015-12-09 at 16:06 -0700, Keith Busch wrote:
> > MAC addresses may be formed using rules based on EUI-64, which is 2 bytes
> > longer than a typical 6-byte MAC. This patch adds a long specifier to
> > the %pM format to support the extended unique identifier.
> >
> > Since there are multiple valid possible permutations of format specifiers,
> > the decoding is done in a loop, and the default ':' separator is
> > initialized at declaration time. A side effect of this allows 'F' and
> > 'R' both be specified, so these are appended to the documentation.
>
> Just thought of this:
>
> An alternative is using a format of "%8phC"
>
> Is there a use case for a bluetooth or FDDI EUI-64?
*facepalm*
I didn't know that format, but it satisfies my needs. I am not aware of
bluetooth or fddi using eui64, so I've no problem withdrawing the patch.
I'll just fix up the one that depended on it.
+Rasmus.
On Thu, Dec 10, 2015 at 5:06 PM, Keith Busch <[email protected]> wrote:
> On Wed, Dec 09, 2015 at 03:21:40PM -0800, Joe Perches wrote:
>> On Wed, 2015-12-09 at 16:06 -0700, Keith Busch wrote:
>> > MAC addresses may be formed using rules based on EUI-64, which is 2 bytes
>> > longer than a typical 6-byte MAC. This patch adds a long specifier to
>> > the %pM format to support the extended unique identifier.
>> >
>> > Since there are multiple valid possible permutations of format specifiers,
>> > the decoding is done in a loop, and the default ':' separator is
>> > initialized at declaration time. A side effect of this allows 'F' and
>> > 'R' both be specified, so these are appended to the documentation.
>>
>> Just thought of this:
>>
>> An alternative is using a format of "%8phC"
>>
>> Is there a use case for a bluetooth or FDDI EUI-64?
>
> *facepalm*
>
> I didn't know that format, but it satisfies my needs. I am not aware of
> bluetooth or fddi using eui64, so I've no problem withdrawing the patch.
> I'll just fix up the one that depended on it.
Of course you might try to add reversed support for %*ph.
Also you may consider print_hex_dump() [hex_dump_to_buffer()], though
it looks like overkill in particular here.
--
With Best Regards,
Andy Shevchenko