integration of 'vimage' patches. (Was "multiple routing tables" in -net)

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.