[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Critique of the Xen Security Process



On Mon, Nov 09, 2015 at 03:48:42PM -0600, Doug Goldstein wrote:
[...]
> As far as the compile time support goes I'm aiming for this as well.
> I've been working on Kconfig support and hope to get that pushed soon
> and the idea being that less mature features can be kept off until
> they're ready to be default on. The downstream distro/product makers can
> then fiddle with these flags to get the hypervisor that fits their needs.
> 
> > Perhaps also to move all the non-hypervisor code, such as all the 
> > toolstacks,
> > stubdom, etc, into separate repos also. For hygiene, if for nothing else.
> 
> From a real high level things should be broken into at least 4 repos:
> 1) hypervisor
> 2) libxl
> 3) userland tools (xl and support scripts)
> 4) stubdom

Stubdom can be a starter. It would be trivial to teach Xen build system
to pull from a repo somewhere.  But then the released tarball will still
contain stubdom source code. I think most distros care about building
from tarball? If what you're thinking is to make stubdom able to do
standalone build so that it doesn't show up in final tarball or xen.git,
that would require a bit of work.

Can you clarify your use case?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.