On Sun, Nov 2, 2014 at 10:48 PM, Antti Kantee <[email protected]> wrote: > On 02/11/14 21:31, Justin Cormack wrote: >> ok as a short term measure I have added a "fiber" option to >> rumprun-posix, but its not 100% useful, as it is not currently working >> with the rumpremote model, but anyway it selects the right _lwp file >> for the threading model. So at least that code is there. > > Nice! (and now we have more options ;) ;) > > What's stopping it from working with remote syscalls? Is there anything > besides the kernel server using pthread calls to provision syscalls onto > workers? (trying to get a sense of the magnitude of the issue)
Well the server should not matter, you should just be able to use a non-fiber server... I can't see any reason to ever support a non pthreads server side, so maybe it would make sense to split out a librumpserver with the rumpuser_sp stuff in it? Although maybe it wuold need a pthread librumpuser anyway? On the client side, the client uses pthreads which might be an issue (allegedly there are some setcontext/tls issues in netbsd) - not clear to me if it could be rewritten not to use threads without further examination. Or why it doesnt try to work anyway - I didnt try very hard, will look again. >>> The Xen _lwp.c could benefit from some easy update-by-copypaste if >>> there's an immediate need. baremetal could also benefit. It's becoming >>> less and less clear to me why we have completely separate by mostly >>> copypasted platform-level repos for posix, Xen and baremetal. >> >> I think merging the rumpfiber, xen and baremetal implementations is >> probably a good start - will take a look at it. Basically will look at >> adding the assembly implementation of stack switching as an option, >> which is the main difference. > > Merging _lwp.c? Where are you going to host the unified implementation? well its not mainly about merging _lwp.c, it is merging some of the rumpuser implementations... ideally to be hosted in netbsd but will see. Needs some thought. > At least Xen and baremetal context switch routines are the same, except > the latter is less creative with pointers. You could just define a > whateverprefix_thread_switch(void'ish *prevtcb, void'ish *nexttcb). > It's difficult to imagine what else would be needed. Well I want to support the assembly versions in userspace for platforms that dont have setcontext, so I wasnt going to do it quite like that... > > In uncensored idea-land: does it make sense to run the rumprun stack > directly on top of libpthread? Or do we want a kvm-esque world where a > native thread (e.g. pthread) is just the unit of potential parallelism > and fibers are used on top of n native threads? That approach would > make things always work the same way regardless of if native threads are > used to achieve parallel execution or not. If the platform does not > have native threads, could just use 1 native "thread". m-n threading is a pain, best avoided, if you want parallelism just use some sort of native thread exclusively. Plus there are some good reasons to avoid pthreads that I am working on. Justin ------------------------------------------------------------------------------ _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
