From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 08:37:21 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C43C16A41F for ; Sat, 29 Oct 2005 08:37:21 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8B6143D46 for ; Sat, 29 Oct 2005 08:37:20 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail07.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j9T8bE43015947 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 29 Oct 2005 18:37:17 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j9T8bEHh054386; Sat, 29 Oct 2005 18:37:14 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j9T8bD6F054385; Sat, 29 Oct 2005 18:37:13 +1000 (EST) (envelope-from pjeremy) Date: Sat, 29 Oct 2005 18:37:13 +1000 From: Peter Jeremy To: Maxim.Sobolev@portaone.com Message-ID: <20051029083713.GX39882@cirb503493.alcatel.com.au> References: <37497.1130570011@critter.freebsd.dk> <436324C6.5040107@portaone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <436324C6.5040107@portaone.com> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: Timers and timing, was: MySQL Performance 6.0rc1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2005 08:37:21 -0000 On Sat, 2005-Oct-29 00:29:10 -0700, Maxim Sobolev wrote: >Poul-Henning Kamp wrote: >>In message <4362BA38.1090603@portaone.com>, Maxim Sobolev writes: >>>You can solve most of those issues by exporting from kernel to userland >>>not only page(s) with actual data, but also page(s) with code to handle >>>that data. Then you can turn syscalls implementation in libc into plain >>>function calls to addresses in that code page(s). This approach can >>>potentially have other interesting applications, for example it will be >>>possible to use processor-specific syscalls instructions without >>>recompiling userland, move some of the ABI code into userland (i.e. >>>freebsd32 layer on amd64) etc. The data I understand - we document a struct that defines the page contents, I'm less sure about the code. The concept is appealing but some more detail would be nice. >>I'm not sure I see much difference between a shared library and this >>solution, but I'm equally sure we'd love to se a prototype before >>we judge it :-) > >Difference is that you won't have additional problems with userland and >kernel versions mismatch and don't need any additional complexity >associated with versioning/fallback logic. I'm not sure I understand how you'll achieve this. How would a userland application locate the appropriate entry points? If the exported code looks like a automagically-mapped shared library, we'd need to embed the ELF symbol table in the kernel as well. How does an application compiled for (eg) FreeBSD-6 handle the code page exported by a FreeBSD-7 kernel? Other options would seem to be: - hard-wire the entry-points into the application or libc (which will basically destroy backward/forward compatibility) - Use explicit branch tables (ala Amiga shared libraries) - there's no infrastructure to support this in FreeBSD. -- Peter Jeremy