Re: [MirageOS-devel] Pioneer project propositions

[Drup <drupyog+caml@xxxxxxxx>]

> Thanks! I'm happy to mentor these initially, once we drill down what they mean 
> :-)
Cool!

> > Unikernel galery (initial idea by mort)
> >
> > By combining functoria and js_of_ocaml, it should be possible to make a webpage 
> > that showcase a set of unikernels (for example, mirage-skeleton). We could then 
> > go further and allow to run functoria in the webpage directly (showing dots and 
> > description, and so on).
> >
> > This project would involved several tasks: First, understand how functoria works (and 
> > modify it if necessary). Then, become familiar with js_of_ocaml and be able to make a 
> > pretty webpage with it. Finally, improve visualisation and documentation informations 
> > that are available through "mirage describe" (and the --dot option) and adapt 
> > them to a web format.
> This one's extremely interesting, but could be broken down a little more before it 
> becomes a pioneer project.  As I understand it, the "gallery" is not referring 
> to possible unikernel applications, but instead to exposing the dependency chain of any 
> application as a web page.
The dependency chain and all the other various informations (keys, 
opam/ocamlfind dependencies, ...). Terminals is a very limited 
environment to expose informations, we could show them much better in 
HTML. The first step would be something static.
> So this would concretely involve compiling the functoria config file into 
> JavaScript and executing it with a UI.  Would an intermediate (and easier) 
> project be to build an interactive tty/console application that would render 
> the various choices as textual dialogs, and then lift the whole lot into JS?  
> That would let `mirage describe` be a bit more like `make menuconfig` in a 
> Linux kernel compilation.
For the first step, I don't really see it as compiling as much as 
"dumping all the unikernel informations". functoria always build all the 
static knowledge given by a config.ml before evaluation (which is what 
you see if you do "mirage describe (--dot)" without any key and without 
--eval). That knowledge can be exported to javascript, similarly to the 
app_info device. The task you propose seems related, but orthogonal.
However, your proposition is really cool too, I like it very much, and I 
think it would actually be reasonably easy! All the tools to do 
incremental evaluation are there, so it just needs a UI.

> > High level devices
> >
> > A good amount of the mirage devices that are implemented right now (in 
> > mirage.ml) are fairly low level. Even the one related to web servers need a 
> > rather large amount of boilerplate to setup (see the static_website_tls 
> > unikernel in mirage-skeleton). The mirage-seal project attempted to improve 
> > that by providing an external tool that would emit the necessary code. It's 
> > also well known that using js_of_ocaml in a unikernel is slightly nightmare-ish 
> > on the build system side.
> >
> > It should be possible to replace all that by new devices that provide 
> > everything directly, using judicious functor applications and configure 
> > scripts. This would involve studying the various idioms that are used (in 
> > mirage-skeleton, mirage-www and other unikernels) and coming up with an API 
> > that is flexible enough to cover all the use cases.
> >
> > I expect this would make it much easier to create new unikernel that do high 
> > level tasks.
> Definitely agree with this one. For Pioneer Projects, how about specific levels:
>
> - Deprecate mirage-seal would be a good one, since it horribly wraps the 
> `mirage` CLI and is a very common usecase
> - A DNS server would be useful (parse zone files -> Xen kernel)
Yes, the new dns library is not yet device-ified.
> - Syslogd device (Gina?)
It should be possible to easily plug that as a replacement log device 
(talex designed the API for that purpose).
> For these, there are some missing device implementations too -- for instance, 
> cloning a Git repository as an option to crunch, so that the configuration can 
> be handled more gracefully.  Anyone got any other missing devices they'd really 
> like to see in the CLI?
As I see it, this would also be the occasion to figure out which API are 
"easily device-ified". Some APIs are very easy (the whole cohttp stack). 
Other, less so (the conduit stuff, and I suspect the DNS api will be 
awkward). It would be interesting to have guidelines for library authors 
on what is a nice API for Mirage.

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