On 28/06/14 13:11, Justin Cormack wrote:
>> 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.
Ok, we can call it posix too, but I thought the conclusion at some point
was to avoid "posix", since the requirements are a superset of posix.
But I really can't think of a better term, and I don't want "posixy" in
the repo name.
It would probably be called hypercall-win32 (since rump kernels have
already been run of windows via cygwin, i.e. posix).
hypercall-baremetal-fibers? Or just hypercall-baremetal? Though,
conceivably, folks might want different schedulers for their baremetal
platforms. I'm not sure we'd have a separate "hypercall" and "appstack"
there (cf. Xen).
>> 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.
I'd like to have a good enough plan(tm) to avoid further renames
(otherwise writing these mails wouldn't be necessary ;). The excuse for
the current need of renaming is that the target went from building
kernel code in userspace to supporting arbitrary application stacks or
arbitrary platforms -- a bit of a paradigm shift.
appstack-{rumprun,xen} clearly don't do the same thing, as one builds
for userspace and the other builds for Xen. I'm thinking about the repo
names from a user perspective, i.e. "hmm, I want to build stuff on Xen,
which repo do I want to clone?". I think the "same thing" you refer to
should be in the tools repo.
> 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.
Then in the ideal case "appstack-posix" would just use said crosscompiler.
>> 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).
Yea. And I'm still not sure ;)
> 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?
Not really a key issue for this thread, but kinda tangential, so here goes:
Per our discussion on irc, _lwp.c should be bundled with the scheduler
(i.e. librumpuser-pthreads/fibers or rumpuser-xen or whatever).
However, since _lwp.c is NetBSD userspace code, it creates the
requirement that NetBSD userspace headers must be available for building it.
------------------------------------------------------------------------------
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
