integration of 'vimage' patches. (Was "multiple routing tables" in
-net)
Julian Elischer
julian at elischer.org
Tue Mar 21 21:14:55 UTC 2006
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.
More information about the freebsd-current
mailing list