Date: Thu, 18 Mar 2004 13:07:57 -0800 (PST)
From: Davide Libenzi <davidel@xmailserver.org>
To: Ingo Molnar <mingo@elte.hu>
cc: Linus Torvalds <torvalds@osdl.org>, Christoph Hellwig <hch@infradead.org>,
       Ulrich Drepper <drepper@redhat.com>,
       Linux Kernel <linux-kernel@vger.kernel.org>,
       Andrew Morton <akpm@osdl.org>
Subject: Re: sched_setaffinity usability
In-Reply-To: <20040318182407.GA1287@elte.hu>
Message-ID: <Pine.LNX.4.44.0403181302460.8512-100000@bigblue.dev.mdolabs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1231
Lines: 30

On Thu, 18 Mar 2004, Ingo Molnar wrote:

> But how about the original issue Ulrich raised: how does user-space
> figure out the NR_CPUS value supported by the kernel? (not the current #
> of CPUs, that can be figured out using /proc/cpuinfo)

Why not a /proc/something? I mean, doesn't glibc already have to handle in 
some way kernels not exporting certain information (in the same way it 
does for missing VDSO)?


> Right now the VDSO mostly contains code and exception-handling data, but
> it could contain real, userspace-visible data just as much: info that is
> only known during the kernel build. There's basically no cost in adding
> more fields to the VDSO, and it seems to be superior to any of the other
> approaches. Is there any reason not to do it?

With /proc/something you can have a single piece of code for all archs 
that exports NR_CPUS. The VDSO should be added to all missing archs. IMO 
performance is not an issue in getting NR_CPUS from userspace.


- Davide


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/