On 01/07/14 21:01, Justin Cormack wrote: > In case anyone is interested, here is my rough TODO list for > rumpfiber... comments welcome.
Put it on the wiki under "project ideas"? 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. quick comments: > 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 ;) > 4. Some way of cleanly integrating _lwp handling > This means sorting out NetBSD env for building and access to internals > in a clean way. Not internals, since _lwp is an exported interface, but regular userspace headers. It will probably be solved as part of the revamp discussed in the "rethinking buildrump.sh" thread. > 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. > 9. Block and network backends > Both of these currently rely on pthreads. The aio block code should > work, if its read thread is replaced by polling in the scheduler. > Probably want a scheduler hook for a simple poll and one for poll() > instead of sleeping when idle. > > 10. rump_server > This should I think now work, bar the etfs stuff which needs 9, so > just needs a build script. etfs doesn't use bio, it just executes read/write calls in the caller context. bio could do the same as an easy first stab. networking is a bit more interesting. I assume you could do a poll-loop with netmap. However, given that you probably want periodic polling for the high-throughput cases to take advantage of batching, a simple sleep loop might be appropriate (that's what dpdk-rumptcpip currently does anyway). ------------------------------------------------------------------------------ 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
