Date: Thu, 18 Mar 2004 13:31:03 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Christoph Hellwig <hch@infradead.org>, Ulrich Drepper <drepper@redhat.com>,
       Linux Kernel <linux-kernel@vger.kernel.org>,
       Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>
Subject: Re: sched_setaffinity usability
Message-ID: <20040318123103.GA21893@elte.hu>
References: <40595842.5070708@redhat.com> <20040318112913.GA13981@elte.hu> <20040318120709.A27841@infradead.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040318120709.A27841@infradead.org>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1303
Lines: 31


* Christoph Hellwig <hch@infradead.org> wrote:

> > or, maybe it would be better to introduce some sort of 'system
> > constants' syscall that would be a generic umbrella for such things -
> > and could easily be converted into a vsyscall. Or we could make it part
> > of the .data section of the VDSO - thus no copying overhead, only one
> > symbol lookup.
> 
> Like, umm, the long overdue sysconf()?  For the time beeing a sysctl
> might be the easiest thing..

i think we want to kill several birds with a single stone, and just make
it part of the VDSO - along with the parameters visible via uname(). 
This would cut another extra syscall, and data copying.

i'm wondering how dangerous of an API idea it is to make these
parameters part of the VDSO .data section (and make it/them versioned
DSO symbols).

The only minor complication wrt. uname() would be sethostname: other
CPUs could observe a transitional state of (the VDSO-equavalent of)
system_utsname.nodename. Is this a problem? It's not like systems call
sethostname all that often ...

	Ingo
-
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/