I have been working on a fully functional xenbus driver for
rumpuser-xen. This driver is a kernel component which calls the Xen
minios xenbus facilities.
It therefore needs to make calls to both the NetBSD kernel facilities
for managing devices and fds (eg, fd_abort, uiomove, etc.) and to the
minios facilities for managing xenbus and making system calls (eg,
xenbus_..., HYPERVISOR_...).
With a small amount of tweaking to the minios headers to suppress some
unnecessary namespace pollution I have been able to get my kernel
component to compile while including _both_ the relevant NetBSD and
minios headers.
But it didn't link because, of course, the kernel symbol namespace is
separated by the symbol renaming, done at the object file level. The
result is that my xenbus component contains undefined references to
symbols such as rumpns_xenbus_event_queue_init.
I think the best way to deal with this is to provide an explicit
escape hatch, whereby a rump component can specify specific symbols to
be excluded from symbol renaming. The result is that a component in
rumpuser-xen will be able not just to #include the minios header
files, but also to link against the symbols in those header files.
This feature probably won't be very useful for a rump kernel component
providing interface to an environment which is not itself intended to
be embedded. And it won't make sense for a rump kernel component
which isn't anyway tied to a specific environment. But minios is
supposed to be embeddable and any namespace clashes between minios and
the things it is supporting should be resolved by changing minios.
And the xenbus driver component is specific to minios on Xen.
So it makes perfect sense to be able to have both the rump kernel
side, and the application side, talk to minios directly.
Doing things this way makes writing the interface component much
simpler: it just needs to provide the appropriate functionality, and
there is no additional namespace boundary to overcome.
The patch required to rumpsrc is very small - see below.
In rumpuser-xen my new component does something like this:
RUMP_SYM_NOMANGLE=|xenbus_|HYPERVISOR_|wake$$|block$$|schedule$$|force_evtchn
So should I send a pull request for the patch to rumpsrc, below ?
(I chose to have the ' ' provided by the expansion site, rather than
the component's Makefile. Whether ' ' are used or not, line-wrapping
would have to be done in the component Makefile with \-newline. And
it wouldn't make any sense for a component to provide anything that
would be expanded by the shell at the expansion site, since the
variables etc. available there aren't known to the component Makefile.
The result is that the component needs only to do escaping for the
benefit of make, which essentially amounts just to doubling $s.)
Thanks,
Ian.
diff --git a/sys/rump/Makefile.rump b/sys/rump/Makefile.rump
index 6b80a11..a039d06 100644
--- a/sys/rump/Makefile.rump
+++ b/sys/rump/Makefile.rump
@@ -208,7 +208,7 @@ __archivebuild: .USE
.endif
for renameobj in
${RUMP_SYMREN:U${.ALLSRC:C/(${RUMPOBJ_NORENAME:ts|})//g}}; do \
${NM} -go $${renameobj} | ${TOOL_AWK} ' \
-
$$NF!~/^'${_PQ}'(rump|RUMP|__|_GLOBAL_OFFSET_TABLE'${_SYMQUIRK}')/ \
+
$$NF!~/^'${_PQ}'(rump|RUMP|__|_GLOBAL_OFFSET_TABLE'${_SYMQUIRK}'${RUMP_SYM_NOMANGLE})/
\
{s=$$NF;sub(/^'${_PQ}'/, "&rumpns_", s); print $$NF, s}'\
| sort | uniq > renametab.$${renameobj}; \
${OBJCOPY} --preserve-dates --redefine-syms \
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
rumpkernel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
