Hello everybody!
I am Hussain, act as student.
I would like to ask few questions about Mirage Unikernel. In fact I built
Unikernel on Mirage because I have a project about ti.
1- How can I test booting speed of Unikernel.
2- After how many pings Unikernel is crash down.
My Regards
On Fri, Dec 2, 2016 at 10:06 PM, Stefano Stabellini <sstabell...@kernel.org>
wrote:
> On Fri, 2 Dec 2016, Lars Kurth wrote:
> > On 01/12/2016 22:36, "Stefano Stabellini" <sstabell...@kernel.org>
> wrote:
> >
> > >On Thu, 1 Dec 2016, Ian Jackson wrote:
> > >> Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision
> > >>making; some new roles and minor changes"):
> > >> > Maybe Ian has some views on what is better from a theoretical
> > >>viewpoint:
> > >> > Voting mechanisms are a bit of a hobby of his
> > >>
> > >> The underlying problem here is that the reality is that the Xen
> > >> Project's by-far most important subproject is the hypervisor; that it
> > >> seems that the governance probably ought to reflect that; but that it
> > >> is difficult to do this without special casing it or providing an
> > >> objective metric of the hypervisor subproject's size.
> > >>
> > >> I don't think it is possible to square this circle. Our options are:
> > >>
> > >> 1. Explicitly recognise the hypervisor subproject as special.
> > >> (This could be done by creating a new `superproject' maturity
> > >> category, or simply by naming it explicitly.)
> > >>
> > >> 2. Do some kind of bodge which tries to reduce the impact of the
> > >> potential unknown management practices of other subprojects
> > >> (particularly, that they might appoint lots of leaders).
> > >>
> > >> 3. Restructure the hypervisor sub-project.
> > >>
> > >> The current proposal is (2) and has the virtue of not incentivising a
> > >> subproject to appoint lots of leaders simply to get more votes
> > >> overall. But it is still rather weak because it has to treat the
> > >> hypervisor subproject as only one amongst many, so hypervisor leaders
> > >> are under-powered and fringe leaders over-powered.
> > >>
> > >> Another way to deal with this would be to split the hypervisor
> > >> subproject (3, above). For example, we could create subprojects for
> > >> some subset of minios, osstest, xtf, various out-of-tree tools,...
> > >> (many of which would have only one leadership team member).
> > >>
> > >> That would mean that the hypervisor-focused maintainers would get
> > >> additional votes via their other "hats". (They would still get a vote
> > >> in the hypervisor subproject, if they have a hypervisor leadership
> > >> position too.)
> > >>
> > >> This is perhaps less unnatural. It still leaves fringe leaders
> > >> somewhat over-powered: this time, leaders of more-hypervisor-related
> > >> (or some such) fringe things, rather than leaders of
> > >> less-hypervisor-related fringe things.
> > >
> > >Istinctively, I don't like the idea of splitting up the hypervisor
> > >project in multiple projects.
> >
> > We could split out the following git repos: mini-os, osstest, raisin,
> > livepatch-build-tools, xtf
> > In terms of contributions per release, there is more activity than
> Windows
> > PV Drivers, which are a separate project.
>
> I see what you meant now. That could be OK.
>
> _______________________________________________
> MirageOS-devel mailing list
> mirageos-de...@lists.xenproject.org
> https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>
--
Hussain Fazul <https://mail.google.com/>
Trainee - Network
ID:031
Technical Trainer College - Riyadh
www.ttcollege.adu.sa
M:00966567506089
E: hussainne...@gmail.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
