08:47 <hannes> mato: btw, why does ukvm and virtio conflict (on the opam level)?

09:04 <mato> hannes: because the downstream layers (ocaml-freestanding, ...) wouldn't know which variant to use if both were installed.

09:05 <mato> hannes: or there would have to be -ukvm and -virtio versions of everything downstream, which is horrible.

09:05 <mato> hannes: there might be some more elegant way of solving it, but i have no idea what that is.

09:06 <hannes> mato: yes, that would be horrible... I'm just wondering which bits (CFLAGS?) are different between kvm and virtio... in the end, the call to ld comes from mirage, and thus is ok to be virtio/kvm specific (in there we know what the user wanted)

09:08 <mato> hannes: CFLAGS are technically the same now, but could be different in the future. LDFLAGS are different in the sense that they pick up a different set of .o's.

09:09 <mato> hannes: the problem is it's not just about mirage -- ocaml-freestanding needs to build with the correct flags. how would it know which to use?

09:10 <hannes> mato: hmm, true... it would be nice to only compile during opam build/install, and defer linking to when the unikernel is built..

09:10 <hannes> but this is wishful thinking right now, and needs more thinking

10:03 <mato> hannes: What do you think of this: https://github.com/mato/solo5/commit/d4656efbf65ded71eceeac822ed42dcb82936635

10:04 <mato> hannes: It's an attempt at making Makefile.ukvm "work" (for some modes of operation) when invoked with just "make" on *BSD.

10:07 <mato> hannes: This hinges on the fact that GNU make doesn't consider .BEGIN as special, so it just ignores it.

10:08 <mato> oh, and also on the fact that a target starting with '.' is not a default target

10:09 <hannes> mato: this is a nice temporary solution, but I think in the end we want to callout to gmake from mirage (after invoking uname -s)..

10:09 <mato> hannes: yeah, though whether you call out to "uname -s" or "opam config var make" is a matter of opinion :)

10:10 <mato> hannes: anyway, I'll put this in, along with renaming the top-level Makefiles (only) to GNUmakefile...

16:02 <kensan> mato: Since #171 has now landed in Solo5 master is it ok if I submit a PR for the Muen port?

16:03 <kensan> mato: One basic question is if the Muen-specifics should reside in a directory separate from kernel/ukvm, e.g. kernel/muen.

16:03 <kensan> mato: Eventhough most of the kernel/ukvm code is (re)used as-is.

16:04 <mato> kensan: This is the next step after #171, since we also need to split up bits of kernel/ to get the ARM64 support in.

16:05 <mato> kensan: Which is the next thing I need to do. So, I'd suggest opening a "DO NOT MERGE" / "RFC" PR, so that I can look at your changes and come up with something that will accomodate both Muen and ARM64...

16:06 <mato> kensan: (Was going to start on this today, but got sidetracked setting up some bare metal CI so that we can get FreeBSD and actual ukvm tests run automatically)

16:07 <mato> kensan: So, please do submit a PR, I just may not merge it as-is.

16:07 <kensan> mato: Thanks for the info. Just wanted to inquire how your plan looks like.

16:09 <kensan> mato: Ok, so I will open a PR and update it according to the feedback.

16:09 <mato> Sounds good.

16:09 <kensan> mato: but if its easier for you I can also just wait until you are through with the ARM64 line of work.

16:10 <mato> kensan: Feel free to open it now, at least I can get an idea of what your changes are.

16:11 <kensan> mato: Understood, will do.