On Sat, Jun 28, 2014 at 12:45 PM, Antti Kantee <[email protected]> wrote: > Ok, so here's the rethink from another perspective, inpired by the "user > in rumpuser-xen doesn't mean anything" comment from a few days ago. The > names of the repos we currently have are a bit of a mess, so which > layers of repos do we have, and can we name them consistently? > > I think we have 3 classes of repos: hypercall, appstack, driver. In > addition, we have (or should have) repos which are a class on their own: > wiki, book, tools, src (and buildrump.sh, which I'll get to shortly). > > The distinction between hypercall and appstack is that hypercalls enable > running the rump kernel, while appstacks enable running "userspace" > applications on the given platform. > > So the current repos on http://repo.rumpkernel.org/ would be: > > rumpfiber -> hypercall-userspace-fibers > rumpuser-xen -> appstack-xen > rumprun -> appstack-userspace > pci-userspace -> driver-pci > netmap-rumptcpip -> driver-netmap > dpdk-rumptcpip -> driver-dpdk > rump-pktgenif -> driver-pktgenif > rumpuser-linuxkernel -> hypercall-linuxkernel > wiki -> wiki > book -> book > > In addition, netbsd-userspace-src and rumpkernel-netbsd-src would be > merged to src-netbsd (per earlier discussion in this thread). > > If we'd some day want to make the pthreads librumpuser hosted on > repo.rumpkernel.org, we'd call it hypercall-userspace-pthreads.
Not sure that "userspace" is the most helpful name. hypercall-posix-pthreads or just hypercall-posix might make more sense, vs eg a hypothetical hypercall-windows. Although not sure what rumpfiber would be called under that scheme, as it is designed to have minimal requirements (eg for embedded bare metal systems). Maybe just hypercall-fibers. > Tools would contain tools, i.e. mostly take over the role of > buildrump.sh. I want to keep the "./buildrump.sh" use case because I've > both advertised "just run buildrump.sh to get a working userspace build" > quite a lot, and also because it's a neat way to introduce someone > unfamiliar with rump kernels to the concept. IOW, we'd have a > buildrump.sh implemented on top of the previous repos. > > I'm not sure if we'd want to have a separate hypercall-xen-minios and > appstack-xen. One could build a Xen hypercall implementation which > isn't based on MiniOS, but is that likely to happen in reality? Also, > if it were to happen, would it screw us if we don't put the extra > abstraction level there up front? MiniOS probably will permeate > "appstack-xen" quite a lot too, so maybe we'll just not worry about it. I wouldnt worry, it could just have another name, or could rename to hypercall-xenminios vs hypercall-xenXX. I think I would call the xen setup hypercall-xen not appstack-xen as that is the key thing it provides. At some point the appstack for xen and rumprun might be merged, as they basically do the same thing. In fact not sure about "appstack". rumprun is a bit of an odd thing, does a mix of functions, one of which is building netbsd userspace, but ideally it just turns into a cross compiler which with tools can build stuff. > Not sure if "driver" needs some extra qualifiers, like > "driver-netif-netmap" or "driver-userspace-pci". currently pci is really driver-pci-uio but I suppose the aim is to add more versions in there (although eg not xen as its too tied in). BTW what did you mean by <pwwka> justin: are you going to work on the "NetBSD userspace headers available when building librumpfiber" thing? in irc yesterday? ------------------------------------------------------------------------------ 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
