[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.0910272220560.9448@chino.kir.corp.google.com>
Date: Tue, 27 Oct 2009 22:24:39 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: Andi Kleen <andi@...stfloor.org>
cc: Ingo Molnar <mingo@...e.hu>, Mike Travis <travis@....com>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Jack Steiner <steiner@....com>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
Yinghai Lu <yinghai@...nel.org>, Mel Gorman <mel@....ul.ie>,
linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org
Subject: Re: [patch v2] x86: reduce srat verbosity in the kernel log
On Wed, 28 Oct 2009, Andi Kleen wrote:
> > + /*
> > + * If the bitmap cannot be listed in a buffer of length
> > + * APICID_LIST_LEN, then it is suffixed with "...".
> > + */
> > + len = bitmap_scnlistprintf(apicid_list, APICID_LIST_LEN,
> > + apicid_map, MAX_LOCAL_APIC);
> > + pr_info("SRAT: PXM %u -> APIC {%s%s} -> Node %u\n",
> > + i, apicid_list,
> > + (len == APICID_LIST_LEN - 1) ? "..." : "",
>
> Is the - 1 really correct? If scnlistprintf follows snprintf semantics then it would not
> be and my understanding is it is supposed to.
>
It is, bitmap_scnlistprintf() returns the number of characters printed to
the buffer minus the trailing '\0', which is different from snprintf().
APICID_LIST_LEN-1 then identifies when the buffer was max'd out. It still
adds a trailing "..." if the list is exactly 128 characters long, but this
isn't addressed to avoid added complexity.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists