From owner-freebsd-current@FreeBSD.ORG Tue Mar 21 21:14:55 2006 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 5724B16A400 for ; Tue, 21 Mar 2006 21:14:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C9F743D46 for ; Tue, 21 Mar 2006 21:14:54 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.146]) ([10.251.23.146]) by a50.ironport.com with ESMTP; 21 Mar 2006 13:14:56 -0800 Message-ID: <44206CCE.2010408@elischer.org> Date: Tue, 21 Mar 2006 13:14:54 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org, Marko Zec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: integration of 'vimage' patches. (Was "multiple routing tables" in -net) 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: Tue, 21 Mar 2006 21:14:55 -0000 Over the years many people have looked at Marco Zec's vimage patches and said how cool they are. I also know that it hasn't really been an option to import them as they are quite pervasive. I do however want to ask the question of "What would it take to allow them to be brought in?" The problems I have seen in the past were basically to do with the interaction between the patches, (which take all the global variables in some modules, and put them into structs, that can be duplicated) and the concept of loadable kernel modules. In some ways this is very similar to the problem faced when trying to implement per-thread global variables (also known as TLS (thread-local strorage)). In both cases, new threads/vimages must get copies of the structures already known about for per-thread/per-vmimage data, and when new libraries/modules are loaded, then they need to immediatly allocate new copies of their structures for all existing threads/vimages. You also need enough reference counting to know when ALL users of a module are not using it, so that it can be unloaded. In the TLS case we use a special data segment on each library to declare the structure, and we use special linker constructs to access the entries in them, dereferencing them via a 'per-thread register' (or equivalent) via possibly a couple of indirections. In the vimage case we have no 'vimage specific pointer' that we could use, though theoretically we could use a pointer in the per-cpu data segment to achieve the same thing (or a pointer in the current thread data, that would achieve it too). Since we do not support TLS in the kernel (maybe we should?) we COULD use the same linker constructs (maybe slightly alterred) to support in-kernel per-vimage VLS (Vimage Local Storage ;-). Alternatively we could just do it "by hand" using macros and stuff.. Possibly still using the data segment trick (usurping the __thread keyword to generate our segment) and letting the loader allocate the structure and always use a macro to access those values. (similar to how we do the 'pcpu()' stuff now). A macro that would have no additional effect if the system were compiled without Vimage support. I see the vimage support as being incredibly useful for embedded work and for many network applications. It'd be interesting to know if people have ideas as to what it would take.