On 19/06/14 12:47, Ian Jackson wrote:
> 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.
I'm a bit uneasy about this patch, but I can come up only with three
questionable arguments:
1) that's not the way I designed things to work (well, duh ;)
2) it can open the pandora's box and cause confusion for people who
don't grasp that the feature can be used only "embedded" envs where you
have full control over all non-NetBSD headers included and routines
called from rump kernel components
3) the division between kernel and a hypercall is weakened, thereby
making it harder to reason about e.g. blocking and dependencies of
kernel code. but, not sure if that's a real concern, can just treat
components using the feature differently
Unless someone can come up with real arguments against the patch, I
think it should go in on the grounds that we don't want to make
development any harder than it needs to be.
> So should I send a pull request for the patch to rumpsrc, below ?
Currently rumpsrc is completely unmodified over NetBSD upstream, so if
nobody comes up with objections, I'll commit the patch to NetBSD
tomorrow and pull it up to rumpsrc.
On a tangent, I don't know if we need to think of a bidirectional patch
flow at some point, but at least so far there have been so little
changes necessary to NetBSD that it's made sense to not have rumpsrc to
diverge over what is in NetBSD-current.
> (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.)
Hmm, I wonder if _SYMQUIRK should be adjusted similarly. I'm not sure
why it is like it currently is.
thanks,
antti
> 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
