On 25/05/15 10:15, Martin Lucina wrote:
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}
That is my interpretation as well.
(and opinion too, so it works out for me ;)
A couple of things that have not been clearly decided yet:
1) Are we sticking with the "baremetal" platform name?
I'm still thinking to rename it to "hw". It's equally non-descriptive,
but shorter, and also has at least some prior art due to "hvm".
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?
Current status: we have no way of specifying what rump kernel components
get linked, apart from editing the Makefile that generates the toolchain.
So, I'm thinking that we could have one which is called "generic"
(symmetry with GENERIC kernel config in *BSD) which includes every
device-type driver available, and "virtio" which includes the virtio
drivers (or "cloud" or "kvm" or "whatever", though I actually object to
"kvm" since the config is not specific to kvm).
Additionally, we'll give some semi-easy way to specify custom boards.
That said, referring to my mail in the "Xen on PV AWS" thread, we still
need to figure out if the component configuration is a "build" thing or
a "rumpbake" thing. In other words, is the board name necessary for the
toolchain, or is it just a parameter to rumpbake? So at least some
thinking is required.
For currently supported targets, that would result in:
rumprun-bmk -> i686-rumprun_baremetal_kvm-netbsdelf
Ok, except I'd call it i686-rumprun_hw_virtio-netbsdelf or perhaps
i686-rumprun_hw-netbsdelf, depending on how the rumpbake discussion pans
out.
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)
Assuming that the purpose of the "netbsd*" bit is the make sure that
configure and other creative scripts use the right toggles, seems
completely wrong to introduce some arbitrary differences to what NetBSD
uses.
3) What arch are we going to use for x86? i686?
Why wouldn't we use the right one, i.e. if you're compiling with
-march=i486 it's i486, with -march=pentiumpro it's i686 etc. ?
Damn this stuff is hard ... and now my head hurts.
