On 04/02/15 16:58, Ian Jackson wrote:
> Antti Kantee writes ("Re: [PATCH] app-tools: Support old -D__RUMPUSER_XEN__
> for now"):
>> Patch is ok since we can't adjust the past, but:
>>
>> Could we instead fix xen.git to not rely on the defines at all? They
>> seem to be an arbitrary difference in pathname (/dev vs. /kern), and
>> something with dlopen() that I'm not quite sure I get, but looks like
>> just not setting XENCTRL_OSDEP would do the right thing.
>
> I don't think that's practical.
>
> -D__RUMPRUN__ is checked in two places in xen.git right now:
>
> * In xc_private.c it is used to disable reliance on the dynamic loader
> (dlopen, et al). (It might be better to gate that more explicitly
> on something in configure, but dynamic loader support is definitely
> a reasonable thing for a platform to lack.)
If the current code works without explicitly disabling it, why go
through the trouble?
Also, there has been some talk that we need to emulate dl*() in rumprun
because especially some language runtimes 100% rely on it.
This is almost the same discussion that we had about php a few weeks
ago, except now we're both rooting for opposite actions ;)
> But there is also reliance in xen.git's configure on the rumpxen arch,
> which has various other effects, notably:
>
> * We select a different implementation of the libxc hypercall drivers.
> Rather than trying to use the userspace privcmd ioctl scheme used
> for running on hosted operating systems, we use the hypercalls
> directly (via the minios entrypoints).
I'm not arguing that configure should be agnostic.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
rumpkernel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
