On 18/06/14 09:14, Justin Cormack wrote: > On Tue, Jun 17, 2014 at 11:58 PM, Antti Kantee <[email protected]> wrote: >> Is there any way we could use branches to our advantage instead of >> separate repos, especially if we can reach the stage where the user and >> kernel sources use the same unmodified sources? > > Yes I guess that could work, have one netbsd-cvs branch and scripts to > create two branches with different sets of directories against it. > That would make maintenance easier, and we could use it with current > rumprun and buildrump as git submodules can point at a branch I think. > All the patches in userspace source are not on parts used by kernel > source.
I'll give it a spin one of these days. Yay, more frobbing with git. I still want to preserve the property of being able to fetch the exact same sources both via cvs and git, so submodules are not applicable. (plus, that property hugely helps in being able to update the sources) > Well at some point, yes, rumprun for netbsd should turn into a script > to run build.sh with a special compiler. I have a plan to get there... > It is still going to be helpful to have a cut down source (without the > four or five compiler sources...) though. That's an ambitious plan, but I'm guessing there will be at least some issues with missing syscalls. Waiting to see what happens. >>> 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... >> >> I'm not sure there's anything wrong with having multiple repos for >> network backends. They are quite different after all. I have a hunch >> that if you're doing high-performance userspace networking, you already >> know which backend you want. > > Main issues are duplication of code and build infrastructure with all > those projects, plus packaging issues - you want the package to just > provide the driver, but currently it builds the whole rump kernel. I > would expect a freebsd package to include the netmap driver for > example as it ships with freebsd. You don't have to build the entire rump kernel if you have rumpmake hanging around. I see hardly any infrastructure or code duplication. The only duplicated code is if_virt, but that's more often than not due to each driver being at a slightly different stage in the chaotic development cycle. And you don't need even that if you have the nb sources around when building (and the driver's use of the if_virt calls happens to match the ones in NetBSD at that time ;) I don't think that affects packaging either, the mindful packager would just pull in the right bits from the right repos for the right platform. I think what we should do is _enable_ packaging, not _dictate_ the packages to a tight degree. At least I don't even possess the clairvoyance to be able to do that. ------------------------------------------------------------------------------ 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
