public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Travis <travis@sgi.com>
To: Bert Wesarg <bert.wesarg@googlemail.com>
Cc: Paul Jackson <pj@sgi.com>,
	mingo@elte.hu, tglx@linutronix.de, hpa@zytor.com,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] x86: add cpus_scnprintf function v2
Date: Mon, 07 Apr 2008 11:22:11 -0700	[thread overview]
Message-ID: <47FA6653.4080707@sgi.com> (raw)
In-Reply-To: <36ca99e90804070707g41d374a5m9b80e77165534f1b@mail.gmail.com>

Bert Wesarg wrote:
> On Mon, Apr 7, 2008 at 10:04 AM, Paul Jackson <pj@sgi.com> wrote:
>> I still have some concerns with this cpus_scnprintf patch.
>>
>>  I've taken them up with Mike offline for initial consideration.
>>
>>  If others have questions, concerns or enthusiasms for this patch,
>>  Mike and I would be interested.
> As long as the only justification for this cpus_scnprintf is human
> readability, I have concerns too.
> 
> Patch 2/4 itself is ok and 4/4 too. The only thing I miss is an export
> of NR_CPUS. So that you know in front of reading a kernel mask, what
> size your bitmap needs. (for example glibc cpu_set_t has only 1024
> bits but has an cpu_set_t with arbitrary size too).
> 
> Bert

Hi Bert,

Yes, sorry, I promised I'd follow up with you on what's happening.  I
did get some feedback on changes proposed but haven't yet tracked down
specific details yet.

Part of the change is readability, but also looking towards the future
of 16k/64k/??? # of cpus, the straight mask approach will overflow the
PAGE_SIZE buffer provided (though some pathological cases will overflow
the range method as well.)  So we'll need some advancement in the format
of the printout.

Another aspect is that this brings the cpumap and cpuset interfaces
closer as the latter already uses the range method.

Thanks,
Mike

      reply	other threads:[~2008-04-07 18:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-05  1:24 [PATCH 0/4] x86: add cpus_scnprintf function v2 Mike Travis
2008-04-05  1:24 ` [PATCH 1/4] " Mike Travis
2008-04-05  1:24 ` [PATCH 2/4] x86: modify show_shared_cpu_map in intel_cacheinfo v2 Mike Travis
2008-04-07 13:57   ` Bert Wesarg
2008-04-07 18:45     ` Mike Travis
2008-04-05  1:24 ` [PATCH 3/4] cpumask: use new cpus_scnprintf function v2 Mike Travis
2008-04-05  1:24 ` [PATCH 4/4] cpumask: add show cpu map functions Mike Travis
2008-04-07  8:04 ` [PATCH 0/4] x86: add cpus_scnprintf function v2 Paul Jackson
2008-04-07  8:16   ` Ingo Molnar
2008-04-07  8:44     ` Paul Jackson
2008-04-07 18:42     ` Mike Travis
2008-04-10 15:30     ` Paul Jackson
2008-04-07 14:07   ` Bert Wesarg
2008-04-07 18:22     ` Mike Travis [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=47FA6653.4080707@sgi.com \
    --to=travis@sgi.com \
    --cc=akpm@linux-foundation.org \
    --cc=bert.wesarg@googlemail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pj@sgi.com \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox