On Monday, 25.05.2015 at 12:30, Antti Kantee wrote:
> >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".
Agreed.
> >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.
I'd forgotten about that. This is also important for scenarios where the
user does not need all of the default set of drivers linked in (embedded
devices, rumprun+Mirage unikernels using the Mirage TCP stack, future Xen
unikernels using vchan only, etc.).
> 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).
Agreed. "generic" and "virtio" sound good to me, and fit with terms people
already use.
> 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.
Conceptually it's not necessary. However I don't see any way of
implementing it.
Currently we have no way to link in drivers and/or board-specific
initialisation code except at the final call to "ld". Therefore, unless
inspiration hits and we figure out the "pseudo-linking" arrangement I don't
think we have any other option than to make the board name part of the
toolchain name. I'm not sure how that will fit in with selecting "optional"
drivers / removing non-default ones as I write above.
> >(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.
Agreed. In fact I already ran into this while porting OCaml to 32-bit
baremetal (had to define SYS_bsd_elf instread of SYS_netbsd).
> >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. ?
Sure. Though we'll still want to provide some default for the majority of
users, I guess that would be i686.
> Damn this stuff is hard ... and now my head hurts.
Yeah. Trying to compensate with coffee...
