On Wednesday, 20.05.2015 at 17:09, Martin Lucina wrote:
> On Wednesday, 20.05.2015 at 13:45, Antti Kantee wrote:
> > Is there still some item awaiting research, or can we finalize this
> > discussion and publish a decision?
>
> I don't think so, but I've been swamped with other work. Thankfully, that
> seems to be coming to a successful result so I'll get onto this ASAP.
Alright, I have a couple of days to sort this out now.
The consensus from the discussion was that we go for the following naming
scheme:
<cpu>-rumprun_<platform>_<board>-netbsd{,elf}
A couple of things that have not been clearly decided yet:
1) Are we sticking with the "baremetal" platform name?
2) Do we want to define some initial "board" types for the currently
supported targets? If so, what?
For the current "rumprun-bmk" toolchain, this is essentially a
"pc-compatible" toolchain. Do we call it "pc", "generic" or instead
something like "kvm" to make it clear that is the (80%) intended target?
For currently supported targets, that would result in:
rumprun-bmk -> i686-rumprun_baremetal_kvm-netbsdelf
For Xen, do we want to make it clear that the current "board" is a PV
target? This affects eg. ARM where all guests are essentially PVH.
See also [1] [2].
For currently supported targets, that would result in:
rumprun-xen -> i686-rumprun_xen_pv-netbsdelf
x86_64-rumprun_xen_pv-netbsd
(the {elf} part should only be relevant for archs that originally used
a.out, or we could just drop it altogether)
3) What arch are we going to use for x86? i686?
Martin
[1] http://xenbits.xen.org/docs/unstable/misc/pvh-readme.txt
[2]
http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions_whitepaper#Xen_on_ARM:_a_cleaner_architecture
