On Tue, Dec 30, 2014 at 12:41 PM, Antti Kantee <[email protected]> wrote: > 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, ...)
Yes it is not clear, it depends on how the process is staged, configure would have to be run quite late. >> 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. Maybe we should spin out a rumpuser git repo, try to sort out these issues and the ABI update and then merge something back into NetBSD once it has settled down. Whats in NetBSD is fine for the purposes it needs to be in tree for (tests), and can probably just sit unchanged for a few months. Justin ------------------------------------------------------------------------------ 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
