Re: [Minios-devel] [MirageOS-devel] [Xen-API] [RFC] Unicore Subproject Proposal

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 13 Sep 2017, at 17:13, Samuel Thibault <samuel.thibault@xxxxxxxxxxxx> wrote:
> 
> Hello,
> 
> Anil Madhavapeddy, on mer. 13 sept. 2017 11:11:03 +0100, wrote:
>> Maintaining a forked MiniOS has been a multi-year source of a maintenance 
>> burden for MirageOS,
> 
> I'm just wondering why this happened?
> 
> The mini-os repository is open for development, it's just a matter of
> agreeing on how to implement features :)

We forked it well before mini-os spun out into a separate repository,
around 5 years ago. And then some features (such as arm32 support)
took around a year to be upstreamed due to multiple iterations of the
patchsets, and we just maintained it in our fork.  None of this is
relevant any more in the brave new world of MiniOS being a separate
repository.

> 
>> One requirement from our side is that we need to strip down MiniOS to remove 
>> even the C xenstore implementation, since we have pure OCaml gnt, xenstore 
>> and device driver implementations.
> 
> That could already be a build option in MiniOS.  It seems it actually
> already is, via $(CONFIG_XENBUS)=n.
> 
> If launching UniCore allows to get momentum to achieve that, I'm all for
> it, I'm just wondering whether the problem is not actually about putting
> a name on it, but just discussing here what is needed, and see how to
> implement it all within the same repository. But again, I understand
> that putting a name can trigger that discussion and be a "let's do it!"
> message :)

It's a combination of both I think.  I had a very quick look at the latest 
mini-os
tree and ran into build problems from the master branch
(e.g. just doing make results in:

gcc -fno-builtin -Wall -Werror -Wredundant-decls -Wno-format 
-Wno-redundant-decls -Wformat -fno-stack-protector -fgnu89-inline 
-Wstrict-prototypes -Wnested-externs -Wpointer-arith -Winline -g 
-D__INSIDE_MINIOS__ -m64 -mno-red-zone -fno-reorder-blocks 
-fno-asynchronous-unwind-tables -DCONFIG_PARAVIRT -DCONFIG_START_NETWORK 
-DCONFIG_SPARSE_BSS -DCONFIG_BLKFRONT -DCONFIG_NETFRONT -DCONFIG_KBDFRONT 
-DCONFIG_FBFRONT -DCONFIG_CONSFRONT -DCONFIG_XENBUS 
-D__XEN_INTERFACE_VERSION__=0x00030205 -isystem /src/include -D__MINIOS__  
-isystem /src/include/x86 -isystem /src/include/x86/x86_64 -c lib/string.c -o 
/src/lib/string.o
lib/string.c: In function '__ffsti2':
lib/string.c:29:27: error: implicit declaration of function 'ffs' 
[-Werror=implicit-function-declaration]
     if (num == 1) return (ffs((int) lli));
                           ^~~
lib/string.c:29:5: error: nested extern declaration of 'ffs' 
[-Werror=nested-externs]
     if (num == 1) return (ffs((int) lli));
     ^~
cc1: all warnings being treated as errors
make: *** [minios.mk:68: /src/lib/string.o] Error 1

and the various combinatorial removal of config options resulted in lots
of small problems that broke the build.  I imagine Unicore's build system
could take a combination of feature flags and focus on make it easier
to maintain the many variants.  Or perhaps MiniOS's could do the same by
improving the Travis file in the repository to test more combinations.
Either way, I didn't quite have the time to do any of that work myself
and I had to context switch to something else after running into the
build problem I'm afraid ;-)

regards,
Anil


_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/minios-devel