On 02/07/14 10:29, Justin Cormack wrote: >> I'm still not sure where you're going with rumpfiber. Is it supposed to >> be the prototype baremetal implementation or a userspace implementation >> with special characteristics. > > Both. See the original rationale. That does make it a bit odd if it was > just for bare metal would just take a lot out...
Am I expected to remember things from a week ago? >>> 2. Split out into modules >>> Started this, eg splitting out rumpuser_file.c as user may want to >>> modify, replace or not include at all. Most of these are just the >>> original ones (eg dl, which an embedded system wont want), but maybe >>> inclined to split out memory allocation, random numbers and so on as >>> these may vary. >> >> For all such rototills, where it makes sense, I hope you perform the >> same for librumpuser. At least currently, I still think it would be >> fairly easy to compile both out of the same codebase with a toggle: one >> uses pthreads, one uses swapcontext. Unless, of course, you're going in >> a different direction than what I'm guessing ;) > > They shouldn't diverge. > > There is the repo question. I could merge original rumpuser in and work on > both or merge rumpfiber into NetBSD or... I think it makes sense to merge in the direction of the master source for librumpuser, i.e. the NetBSD tree (for now). >>> 7. Less locking >>> I think Antti was suggetsing that something even more optimised than >>> locks_up.c possible without concurrent threads. >> >> It doesn't affect the rumpfiber side, only atomic ops: if we assume that >> all threads accessing rump kernels run use fibers, we don't need atomic >> ops even in scheduler.c. That's, what, 3 atomic ops total. Not really >> sure if it's going to be measurably better than what you can do with >> RUMP_LOCKS_UP. >> >> Notably, currently a RUMP_LOCKS_UP build will use real atomic ops >> everywhere. The first step would be to make that build use >> pseudo-atomic ops, i.e. ones where semantics are maintained without >> "lock" instructions. > > The uncontended cases should be fast in theory so it is probably a minimal > win but may still be worthwhile. For atomic ops? There is no "contended" case for the individual atomic op, so not sure what you mean. ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
