On 28/12/14 11:34, Justin Cormack wrote:
> I think the best thing to do is to add it into the ./configure step
> for rumpuser, so if you don't have setcontext it uses this. However
> one of the points of this code is also to use the same code for
> xen/baremetal, so are we going to upstream all the xen and baremetal
> specific code into NetBSD, using configure to work out what kind of
> build env we are in? Possibly with some --enable-xen options? Not
> necessarily all the coed, but enough to build the hypercall layer,
> which still expects some platform functions of course (mmap, malloc
> etc).

I don't think xen/baremetal should go into the NetBSD tree.  The point 
of doing development outside of the NetBSD tree is to enable rapid 
development and easy contributions from individuals who do not have a 
NetBSD commit bit.  If anything, we should move librumpuser out of the 
NetBSD tree, like you point later in your mail.

Regardless of where the code resides, I'm not sure we can use autoconf 
for selecting the build target.  For one, we can't run autoconf before 
we have a target env available, which is very late in the build process 
for non-hosted envs (xen, baremetal, ...)

> It will mean that the librumpuser ends up with a lot of
> optional/swappable parts. Thats already somewhat the case, with
> pthreads, fibers and no threading options already, plus various other
> bits are optional (dl support might be configured out). Plus a bunch
> of implementations/modifications of stuff.

Well, they probably shouldn't be in librumpuser at all.  There are three 
parts in the lower layers of the rumprun stack:

3: rump kernel
2: rumpuser
1: firmware (e.g. hacked-up minios or bmk)

Thread context switching is a function of "1".  The fiber scheduler 
logically belongs there.  It's just been convenient to keep it in 
librumpuser so far, but maybe we should have a fiber component that we 
can build/link for all platforms.

Yes, the dl interfaces being a part of librumpuser is a mistake, but so 
far living with it has been less painful than fixing it.

------------------------------------------------------------------------------
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

Reply via email to