[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47FA6653.4080707@sgi.com>
Date: Mon, 07 Apr 2008 11:22:11 -0700
From: Mike Travis <travis@....com>
To: Bert Wesarg <bert.wesarg@...glemail.com>
CC: Paul Jackson <pj@....com>, mingo@...e.hu, tglx@...utronix.de,
hpa@...or.com, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] x86: add cpus_scnprintf function v2
Bert Wesarg wrote:
> On Mon, Apr 7, 2008 at 10:04 AM, Paul Jackson <pj@....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
--
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