On Tue, Jun 17, 2014 at 4:40 PM, Antti Kantee <[email protected]> wrote: > 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.
Ah ok, ignore that then. > It's just more logical to not have one hypercall implementation as the > default in buildrump.sh. Agreed. >> 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. Yes I saw that. > 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 was thinking one kernel tree as it is now, and then one kernel+userspace tree that can build both. Still two trees but you choose the one you want depending if you are going to build userspace or not. That should be fairly simple by adding the kernel paths to the userspace checkout script. Select which you want with checkout or checkoutall say. Currently userspace source is quite a bit smaller (whole repo) but I can see it getting a bit bigger; the other option is just to have a single repo with both. Since git 1.9 shallow clones work properly ie you can clone and push from them properly, so shouldnt worry about history getting huge - currently its the checked out tree that takes all the space though. So maybe we should just merge them... > 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. The patches are now down to just the libc Makefiles, and I think even those can get smaller before upstreaming. >> 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. Yes, assuming will for now. > 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) Excellent. >> 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? ;) Main issue is that I need a copy for running the tests against rump. Might just always test against head, unlikely to break it very often. >> 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. Yes. >> 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. Also we have repos for every network backend, rather than eg having some type of autoconfig like approach that you can specify that you want to build a netmap interface and a snabb one... Justin ------------------------------------------------------------------------------ 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
