On 17/06/14 14:50, Justin Cormack wrote: > Some somewhat /dev/random thoughts:
Right back at you ;) > 1. splitting out 1 would mean you could do sane things like build > kernel with -nostdinc so you can be sure there is no leakage from host > - you can build -k like that now, but rumpuser has host deps Yes, but the kernel is built with -nostdinc all the same already. I'm not sure I see change over the existing ./buildrump.sh -k. It's just more logical to not have one hypercall implementation as the default in buildrump.sh. > 2. buildnb.sh from rumprun is really hard to make reuse a build from > buildrump as we have seen recently. It seems to make sense to > basically merge much of it into buildrump.sh. This has downsides > (managing the source, as having a nice small source for buildrump is > good, while I can see buildnb having a pretty big source. Plus rumprun > still has patches for now. It might be easier to add the kernel > sources into the userspace sources, so you could choose either the > kernel only source tree or the kernel+userspace tree) I don't know if you saw it, but yesterday I experimented with a subroutine-based approach for rumprun's buildnb.sh and rumpuser-xen's buildxen.sh. I'd say it worked. It's not awesome, but at least a minor improvement over the copypasta. What do you specifically propose with the source trees? Note that the kernel source tree overlaps the user source tree. I do find it rather annoying that we have two separate trees, but not sure how to fix it. I don't think we should design anything based on the user part of the source tree requiring patches. The patches should be mostly manual to eliminate... manual and annoying. > 3. I am about to start working on my hypercall implementation thats > non pthread based, which is a sort of hybrid between xen and posix. So > there will be another general purpose version. I really dont want to > make yet another repo with a linked copy of buildrump... linked copy == git submodule? It will probably be the best way at least for a while, though hoping things will settle down. Speaking on non-pthread based, I started looking at the _lwp_foo() calls for Xen again last night, to get pthreads going there. I'll hopefully have it polished up a bit in a few days. You should have the previous version in private email from some time before Easter (and everyone else interested can have it if they want to, just send mail. it's a bit messy now and therefore I'm not distributing it with exceeding vigor) > 4. I would quite like to take the subrepo copy out of ljsyscall and > just test against external versions, should do that anyway. I always test ljsyscall against an external version, but of course I usually have a few external versions lying around to choose from. ljsyscall is a delightfully simple case, though, and just pointing LD_LIBRARY_PATH is enough. The only thing I can think of with the submodule is that it's easier to pick up fixes. But you know better how complete ljsyscall is now. Go for it? ;) > 5. I guess if rumpuser was split out, its master copy could be outside > NetBSD, with NetBSD just having an import (still in base as needed for > tests). This would make some more sense in a way as it is not in any > way NetBSD specific, and (was looking at this today) despite the > comments at the top of rumpuser_port.h about maybe using the generic > NetBSD compat, that is not really feasible, as it uses way more stuff, > rather than just minimal Posixy stuff (eg might want to merge my aio > block dev implementation). That's a possibility, though without it solving a clear problem, I'm not sure I'd bother. I think I wrote the comment to preempt anyone from demanding that it should be done when the work was at its early stages ;) The implementation still does need some autoconfig-like approach. > 6.The IO hypercalls are an issue, I wonder if they could be made more > generic. I had some thoughts on this a while back, will look for them. The block I/O subsystem needs work in a number of ways, including ways to use alternative backends. ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
